附錄D：第 5 版中可能會(huì)對(duì)第 3 版產(chǎn)生兼容性影響的更正及澄清

全體：在第 3 版規(guī)范中像“就像用表達(dá)式 new Array() 一樣”這樣的短語的意思受到了誤解。第 5 版規(guī)范中，對(duì)標(biāo)準(zhǔn)內(nèi)置對(duì)象、屬性的所有內(nèi)部引用和內(nèi)部調(diào)用相關(guān)文本描述，都做了澄清：應(yīng)使用實(shí)際的內(nèi)置對(duì)象，而不是對(duì)應(yīng)命名屬性的當(dāng)前動(dòng)態(tài)值。

 11.8.2，11.8.3，11.8.5：ECMAScript 總體上是以從左到右的順序解釋執(zhí)行，但是第 3 版規(guī)范中 > 和 <= 運(yùn)算符的描述語言導(dǎo)致了局部從右到左的順序。本規(guī)范已經(jīng)更正了這些運(yùn)算符，現(xiàn)在完全是從左到右的順序解釋執(zhí)行。然而，這個(gè)對(duì)順序的修改，如果在解釋執(zhí)行過程期間產(chǎn)生副作用，就有可能被觀察到。

 11.1.4：第 5 版澄清了 Array Initialiser 結(jié)束位置的尾端逗號(hào)不計(jì)入數(shù)組長(zhǎng)度。這不是對(duì)第 3 版語義的修改，但有些實(shí)現(xiàn)在之前可能對(duì)此有誤解。

 11.2.3：第 5 版調(diào)換了算法步驟 2 和 3 的順序。第 1 版一直到第 3 版規(guī)定的順序是錯(cuò)誤的，原來的順序在解釋執(zhí)行 Arguments 時(shí)有副作用，可能影響到 MemberExpression 的解釋執(zhí)行結(jié)果。

 12.14：在第 3 版中，對(duì)于傳給 try 語句的 catch 子句的異常參數(shù)的名稱解析，用與 new Object() 一樣的方式創(chuàng)建一個(gè)對(duì)象來作為解析這個(gè)名稱的作用域。如果實(shí)際的異常對(duì)象是個(gè)函數(shù)并且在catch 子句中調(diào)用了它，那么作用域?qū)ο髮?huì)作為 this 值傳給這個(gè)調(diào)用。在函數(shù)體里可以給它的 this 值定義新屬性，并且這些屬性名將在函數(shù)返回之后在 catch 子句的作用域內(nèi)變成可見的標(biāo)識(shí)符綁定。在第 5 版中，如果把異常參數(shù)作為函數(shù)來調(diào)用，傳入的 this 值是 undefined 。

 13：在第 3 版中，有 Identifier 的 FunctionExpression 產(chǎn)生式的算法，用與 new Object() 一樣的方式創(chuàng)建一個(gè)對(duì)象并加入到作用域鏈中，用來提供函數(shù)名查找的作用域。標(biāo)識(shí)符解析規(guī)則（第 3 版里的 10.1.4 ）會(huì)作用在這樣的對(duì)象上，如果需要，還會(huì)用對(duì)象的原型鏈來嘗試解析標(biāo)識(shí)符。這種方式使得 Object.prototype 的所有屬性以標(biāo)識(shí)符的形式在這個(gè)作用域里可見。實(shí)踐中，大多數(shù)第 3 版的實(shí)現(xiàn)都沒有實(shí)行這個(gè)語義。地 5 版更改了這里的語義，用一個(gè)聲明式環(huán)境記錄項(xiàng)來綁定了函數(shù)名。

 14：在第 3 版中，產(chǎn)生式 SourceElements : SourceElements SourceElement 的算法不像相同形式的 Block，對(duì) statement 的結(jié)果值做正確的傳遞。這可導(dǎo)致 eval 函數(shù)解釋執(zhí)行一個(gè) Program 文本時(shí)產(chǎn)生錯(cuò)誤的結(jié)果。實(shí)踐中，大多數(shù)第 3 版的實(shí)現(xiàn)都做了正確的傳遞，而不關(guān)心第 5 版規(guī)定了什么。

 15.10.6：RegExp.prototype 現(xiàn)在是一個(gè) RegExp 對(duì)象，而不是 Object 的一個(gè)實(shí)例。用 Object.prototype.toString 可看到它的 [[Class]] 內(nèi)部屬性值現(xiàn)在是 "RegExp"，不是 "Object"。