這個也不會,回家種田去吧你
順便我們來談談delete的用法
幾個禮拜前, 我有了個機會去翻閱Stoyan Stefanov的Object-Oriented Javascript 一書. 這本書在亞馬遜上擁有很高的評價(12篇評論, 5顆星), 所以我很好奇地想看看它到底是不是那麼值得推薦的一本書, 於是我開始閱讀函數的那章. 我非常欣賞這本書解釋事物的方式, 例子們被以一種非常漂亮, 漸進的方式被組織起來, 看起來即便是初學者也能夠輕鬆掌握這些知識. 然而, 幾乎是立刻, 我就發現了一個貫穿整個章節的有趣的誤解——刪除功能函數. 另外還有一些其它錯誤(例如函數聲明與函數表達式的區別), 但是我們目前將不去討論它們.
這本書聲稱:
"函數被當作像一般變數一樣對待-它可以被複製到不同的變數中, 甚至被刪除". 在這個解釋後面附加了這樣一段範例:
忽略掉一些漏掉的分號, 你能看出這幾句程式碼的錯誤在哪麼? 顯然, 錯誤在於刪除sum這個變數的操作是不會成功的. delete表達式不應該回傳true,並且typeof sum也不應該返回"undefined". 這一切都因為在JavaScript中刪除變數是不可能的. 至少, 在這種聲明方式下是不可能的.
所以, 在這個例子中到底發生了什麼? 它是一個錯誤麼? 抑或是一個特殊用法? 大概不是這樣的. 這一段代碼事實上是Firebug控制台中的真實輸出, Stoyan一定是使用了它作為快速測試的工具. 這幾乎就好像是Firebug遵守了其它一些delete的規則一樣. 是Firebug導致了Stoyan誤入歧途! 所以, 這兒到底發生了什麼?
在回答這個問題之前, 我們首先需要理解delete運算符到底在JavaScript中是如何工作的: 到底什麼能夠被刪除, 什麼不能夠被刪除? 今天, 我將嘗試著詳細解釋這個問題. 我們將看看Firebug的"奇怪"行為並且意識到它其實並不是那麼奇怪. 我們將深入了解在聲明變量, 函數, 給屬性賦值和刪除它們的這些場景背後到底隱藏了什麼. 我們將看看瀏覽器的相容性和一些最臭名昭著的bug. 我們還將討論ES5的嚴格模式, 和它如何改變delete操作符的行為.
我將交換使用JavaScript和ECMAScript, 它們都意味著ECMAScript(除非明顯地談論Mozilla的JavaScript實作)
不出所料, 在網路上, 對delete的解釋是相當稀缺的. MDC article大概是最好理解的資源了, 但是, 不幸的是, 它缺失了這個主題的一些有趣的細節. 奇怪的是, 其中一個被遺忘的東西就是Firebug的奇怪表現的原因. 而MSDN reference在這些方面幾乎是無用處的.
Theory
那麼, 為什麼我們能夠刪除物件的屬性:
卻不能刪除這樣宣告的物件:
或函數呢:
注意: 當一個屬性無法被刪除時,delete操作符只會回傳false
要理解這個, 我們首先需要掌握這些有關變數實例和屬性特性的概念—這些概念很不幸地, 很少在JavaScript書中被提及. 我將試著在接下來的幾個段落中簡單地複習一下這些概念. 這些概念是很難理解的!如果你不在乎"為什麼這些東西會以這種方式工作"的話,盡情跳過這一章節好了.
程式碼的型別:
在ECMAScript中, 有3種不同類型的可執行代碼: 全域代碼(Global code), 函數代碼(Function code)和Eval代碼(Eval code). 這些類型從名稱上來說或多或少是有自解釋性的, 這裡有一個簡短的概述:
當一段原始碼被看成程式(Program)時, 它將在全域環境下被執行, 並且被認為是全域程式碼(Global code). 在一個瀏覽器環境中, 腳本元素的內容通常被解釋為程式, 因此被當作全域程式碼來執行.
任何直接在一個函數中執行的程式碼顯然被認為是函數程式碼(Function code). 在瀏覽器中, 事件屬性的內容(如
)通常被解釋成函數碼.
最後, 被應用到內建函數eval的程式碼文字被解釋成Eval程式碼(Eval code). 很快我們會發現為什麼這種類型是特殊的.
執行上下文(Execution context):
當ECMAScript程式碼執行時, 它通常會發生在特定的執行上下文中.執行上下文是一個有些抽象的實體概念, 它能幫助理解範圍(Scope)和變數實例(Variable instantiation)是如何運作的.對三種可執行代碼的每一種, 都有一個執行上下文相對應. 當一個函數被執行的時候, 我們說"程序控制進入了函數代碼的執行上下文"; 當一段全局代碼被執行時, 程序控制進入了全域程式碼的執行上下文, 等等.
如你所見, 執行上下文可以在邏輯上構成一個堆疊. 首先, 可能有一段全局程式碼和其自己的執行上下文, 然後這段程式碼可能會調用一個函數, 並帶著它(函數)的執行上下文. 這段函數可以呼叫另外一個函數, 等等等等. 即使函數是遞歸呼叫的, 每次呼叫時被也會進入一個新的執行上下文.
活動物件(Activation object) / 變數物件(Variable Object):
每一個執行上下文都有一個跟其所關聯的所謂變數物件(Variable Object). 類似於執行上下文, 變數物件是一個抽象實體, 一種用來描述變數實例的機制. 有趣之處在於,在原始碼中宣告的變數和函數通常會被當做屬性(properties)增加到這個變數物件上.
當程式控制進入全域程式碼的執行上下文時, 一個全域物件(Global object)被用來作為一個變數物件. 這正是為什麼宣告為全域的函數變數會變成全域物件屬性的原因.
var foo = 1;
GLOBAL_OBJECT.foo; // 1
foo === GLOBAL_OBJECT.foo; // true
function bar(){}
typeof GLOBAL_OBJECT.bar; // "function"
GLOBAL_OBJECT.bar === bar; // true
好, 所以全域變數會變成全域物件的屬性, 但是局部變數(那些在函數程式碼中定義的變數)會發生什麼事呢? 其實它們的行為也非常類似: 它們會變成變數物件(Variable object)的屬性. 唯一的不同在於, 當在函數程式碼中時, 一個變數物件並不是全域物件, 而是所謂的活動物件(Activation object). 活動物件在會每次進入函數程式碼的執行上下文時被創建.
並不是只有在函數程式碼中宣告的變數和函數會變成活動物件的屬性; 這也會在每個函數參數(對應對應的形式參數的名稱)和一個特殊的Arguments物件(以arguments為名稱)上發生. 注意, 活動對像是一個內部描述機制, 在程式碼中並不能被存取.
屬性的特性(property attributes)
我們幾乎是已經在這裡了. 既然我們已經很清楚在變數上發生了什麼(它們變成了屬性), 唯一剩下的需要理解的概念就是屬性的特性(property attributes)了. 每一個屬性可以擁有0個或多個特性, 它們從以下集合中選取: ReadOnly, DontEnum, DontDelete和Internal. 你可以把它們認為是flags —— 一種特性可以在屬性中存在, 也可以不存在. 對於我們今天的討論來說, 我們只對DontDelete有興趣.
當被宣告的變數和函數成為變數物件(或函數程式碼的活動物件, 或全域程式碼的全域物件)的屬性時, 這些屬性在建立時就帶上了DontDelete的特性. 然而, 任何明確(或隱式)的屬性賦值所建立的屬性將不會被帶上DontDelete特性. 這就是為什麼我們能夠刪除一些屬性, 但刪除不了其它的.
內建物件和DontDelete
所以, 這就是有關它(DontDelete)的所有: 屬性的一個特殊特性, 用來控制這個屬性是否能夠被刪除. 注意, 有些內建物件的屬性是指定含有DontDelete的, 所以無法被刪除. 如特殊的arguments變數(或, 正如我們現在所知道的, 一個活動物件的屬性)擁有DontDelete. 函數實例的length屬性也具有DontDelete屬性.
函數參數所對應的屬性也是從建立開始就擁有DontDelete特性的, 所以我們也無法刪除它.
未宣告的賦值:
你可能還記著, 未聲明的賦值會在全局對像上建立一個屬性, 除非這個屬性已經在這個作用域鏈中全局對象之前的其它地方被找到. 並且, 現在我們知道屬性賦值和變量聲明的不同之處-後者會設定DontDelete屬性, 但前者不會. 我們必須清楚, 為什麼未宣告的賦值會建立一個可刪除的屬性.
請注意: 特性是在屬性被創建時被決定的, 之後的賦值不會修改已存在屬性的特性. 理解這一點區別非常重要.
Firebug的困惑:
在Firebug中發生了什麼? 為什麼在console中聲明的變數可以被刪除, 這不是違背了我們之前所學到的知識麼? 嗯, 就像我之前所說的那樣, Eval程式碼在面對變數宣告時會有特殊的表現. 在Eval中宣告的變數其實是作為不帶DontDelete特性的屬性被建立的.
同樣, 類似的, 當在函數程式碼中呼叫時:
eval('var foo = 1;');
foo; // 1
delete foo; // true
typeof foo; // "undefined"
})();
這就是Firebug反常行為的依據. 在console中的所有文本都會被當做Eval代碼來解析和執行, 而不是全局或函數代碼. 顯然, 這裡聲明的所有變量最後都會成為不帶DontDelete特性的屬性, 所以它們都能被輕鬆刪除. 我們需要了解這個在全域程式碼和Firebug控制台之間的差異.
透過Eval來刪除變數:
這個有趣的eval行為, 再加上ECMAScript的另一個方面, 可以在技術上允許我們刪除"non-deletable"的屬性. 有關函數聲明的一點是, 它們能夠覆蓋相同執行上下文中同名的變量.
注意函數宣告是如何獲得優先權並且覆蓋同名變數(或者, 換句話說, 在變數物件中的相同屬性)的. 這是因為函數宣告是在變數宣告之後被實例化的, 並且被允許覆蓋它們(變數宣告).函數宣告不只替換掉一個屬性的值, 它還會替換掉那個屬性的特性. 如果我們透過eval來宣告一個函數, 那個函數就應該會用它自己的特性來替換掉原有的(被替換的)屬性的特性. 並且, 由於通過eval聲明的變量會創建不帶DontDelete特性的屬性, 實例化這個新函數將會實際上從屬性中刪除已存在的DontDelete特性, 從而使得一個屬性能夠被刪除(並且, 顯然會將其值指向新建立的函數).
不幸的是, 這種"欺騙"在目前的任何實現中都不起作用. 也許我在這漏掉了什麼, 或者是這種行為只是太晦澀了以至於實現者都沒有註意到它.
瀏覽器相容性:
在理論上了解事物是如何工作的是有用的, 但是實踐卻是最重要的. 當面對變量/屬性的創建/刪除時, 瀏覽器有遵循標準麼? 答案是: 在大多數情況下, 是的.
我寫了一個簡單的測試集來測試瀏覽器對於delete操作符的兼容性, 包括在全局代碼, 函數代碼和Eval代碼下的測試. 測試集檢查了delete操作符的返回值和屬性值是否(像它們應當表現的一樣)真的被刪除了. delete的返回值並不像它的真實結果一樣重要. 如果delete返回true而不是false, 這其實並不重要, 重要的是那些擁有DontDelete特性的屬性沒有被刪除,反之亦然.
現代瀏覽器大致上來說是相當兼容的. 除去了我之前提到的eval特點, 如下的瀏覽器通過了全部的測試集: Opera 7.54 , Firefox 1.0 , Safari 3.1.2 , Chrome 4 .
Safari 2.x 和3.0.4在刪除函數參數時有問題; 這些屬性看起來是不帶DontDelete被創建的, 所以可以刪除它們. Safari 2.x有更多的問題——刪除非引用類型變數(如: delete 1)會拋出異常; 函數宣告會建立可刪除的屬性(但是, 奇怪的是, 變數宣告卻不會); eval中的變數宣告會變成不可刪除的(但是函數聲明是可刪除的).
跟Safari類似, Konqueror(3.5, 不是4.3)會在刪除非引用型別時拋出異常(如: delete 1), 並且錯誤地讓函數變數變為可刪除的.
譯者註:
我測試了最新版本的chrome和firefox以及IE, 基本還是保留在除23,24會fail其它均pass的情況. 同時測試了UC和一些手機瀏覽器, 除了諾基亞E72的自帶瀏覽器還會Fail 15,16之外, 其餘的自帶瀏覽器大都與桌面瀏覽器效果一樣. 但值得一提的是, Blackberry Curve 8310/8900的自帶瀏覽器可以pass測試23, 令我很驚訝.
Gecko DontDelete bug:
Gecko 1.8.x 瀏覽器—— Firefox 2.x, Camino 1.x, Seamonkey 1.x等等. —— 表現出了一個非常有趣的bug, 對屬性的明確賦值會刪除它的DontDelete特性, 即使這個屬性是透過變數宣告或函數宣告創造的.
令人吃驚的是, Internet Explorer 5.5 - 8 通過了完整的測試集, 除了刪除非引用類型(如: delete 1)會拋出異常(就像舊的Safari一樣). 但是在IE下有更嚴重的bugs, 它不是那麼明顯. 這些bugs跟Global object有關.
IE bugs:
這整章都在說Internet Explorer的bugs? 哇! 真是令人吃驚!
在IE中(至少是IE 6-8), 以下表達式會拋出異常(當在全域程式碼中執行時):
this.x = 1;
delete x; // TypeError: Object doesn't support this action
這一個也會, 但是會拋出不同的異常, 這使得事情更有趣了:
var x = 1;
delete this.x; // TypeError: Cannot delete 'this.x'
這看上去好像是在IE中, 全局代碼中的變量聲明沒有在全局對像上創建屬性. 通過賦值來創建屬性(this.x = 1)和之後通過delete x來刪除它會拋出錯誤. 通過聲明來建立屬性(var x = 1)並且在之後透過delete this.x來刪除它會拋出另一個錯誤.
但這還不是全部. 通過顯式賦值來創建屬性事實上總會引起在刪除時的拋出異常. 這裡不止有錯誤, 而且所創建的屬性似乎會擁有DontDelete特性, 而這當然是不應該具有的.
this.x = 1;
delete this.x; // TypeError: Object doesn't support this action
typeof x; // "number" (still exists, wasn't deleted as it should have been!)
delete x; // TypeError: Object doesn't support this action
typeof x; // "number" (wasn't deleted again)
現在, 我們會認為 在IE下, 未宣告的賦值(應當在全域物件上建立屬性)確實會建立可刪除的屬性.
x = 1;
delete x; // true
typeof x; // "undefined"
但是, 如果你是同透過全域程式碼中的this引用來刪除這個屬性的話(delete this.x), 就會彈出一個類似的錯誤.
x = 1;
delete this.x; // TypeError: Cannot delete 'this.x'
如果我們想要歸納一下這種行為的話, 看起來是從全域程式碼中使用delete this.x來刪除變數從來不可能成功. 當問題中的屬性透過顯式的賦值(this.x = 1)來創建時,delete拋出了一個錯誤; 當屬性是透過未宣告的賦值(x = 1)或透過宣告(var x = 1)來建立時, delete拋出另外一個錯誤.
delete x, 另一方面來說, 應當只在屬性是透過明確賦值來建立時拋出錯誤-this.x = 1.如果一個屬性是透過宣告來建立的(var x = 1) , 刪除操作從來不會發生, 並且刪除操作會正確地返回false. 如果一個屬性是通過未聲明的賦值來創建的(x = 1), 刪除操作會像期望地一樣工作.
我這9月又思考了一下這個問題, Garrett Smith建議說在IE下,
"全域變數物件(The global variable object)是實作為一個JScript物件的, 並且全域物件是由host來實現的".
Garrett使用了Eric Lippert's blog entry作為參考.
我們多多少少可以透過實作一些測試來確認這個理論. 注意到this和window看起來是應當指向同一個物件的(如果我們能夠信任===運算子的話), 但是變數物件(函數聲明所在的那個對象)卻與this所指向的不同.
getBase() === this.getBase(); // false
this.getBase() === this.getBase(); // true
window.getBase() === this.getBase(); // true
window.getBase() === getBase(); // false
誤解:
理解事物為何以那種方式工作的美是不可低估的. 我在網絡上見過一些有關delete操作符的誤解. 例如, 這個Stackoverflow上的答案(擁有令人吃驚的高rating), 自信地解釋
"當目標運算元不是一個物件屬性時, delete應是無操作的".
現在既然我們已經理解了delete操作行為的核心, 這個答案的錯誤也就變得顯而易見了. delete並不會去區分因為變量和屬性(事實上, 對於delete來說, 它們都是引用類型)並且事實上只關心DontDelete特性(和屬性本身是否存在).
看到各種誤解互相反駁也是非常有趣的, 在一個相同的話題中一個人首先建議只delete變數(這將不會有效果, 除非它是在eval中聲明的), 而另一個人提供了一個錯誤的修正說明delete是如何在全域程式碼中用於刪除變數, 而在函數程式碼中卻不行.
對於網路上JavaScript的解釋要格外小心, 理想的方法是總去理解問題的本質. ;)
delete和宿主物件(Host Object):
delete的演算法大概是這樣的:
如果運算元不是引用型別, 則回傳true
如果物件沒有這個名字的直接屬性, 回傳true(正如我們所知, 物件可以是活動物件或全域物件)
如果屬性存在但是有DontDelete特性, 回傳false
其它情況, 刪除屬性並且傳回true
然而, delete操作符在宿主物件上的行為是難以預測的. 並且這種行為實際上並沒有錯: (根據標準), 宿主物件是被允許對於像read(內部[[Get]]方法), write (內部[[Put]]方法)和delete(內部[[Delete]]方法)其中幾個運算子實現任何行為的. 這種對自訂[[Delete]]行為的寬限就是將宿主物件變得如此混亂的原因.
我們已經看過了一些IE的怪癖, 刪除特定的物件(顯然是指被實現為宿主物件的)會拋出錯誤. Firefox的一些版本在刪除window.location的時候會拋出. 當操作數是宿主物件時, 你不可以信任delete的回傳值. 讓我們來看看在Firefox中發生了什麼:
delete window.alert; // true
typeof window.alert; // "function"
刪除window.alert返回true, 即使這個屬性完全沒有任何應該導致這樣的結果的理由. 它將解析為一個引用(所以不會在第一步就返回true). 這是個window對象的直接屬性(所以不會在第二步回傳true). 所以delete唯一能夠回傳true的情況就是到達第四步並且真正刪除那個屬性. 然而, 這個屬性從未被刪除.
這個故事的寓意是: 永遠不要相信宿主物件.
ES5 嚴格模式:
所以, 嚴格模式的ECMAScript5給我們帶來了什麼? 它介紹了很少的一些限制. 當delete操作符的表達式是一個變量的直接引用, 函數參數或者函數標示符時, 語法錯誤將會被拋出. 另外, 如果屬性具有內部特性[[Configurable]] == false, 則一個類型錯誤將會被拋出.
另外, 刪除未宣告的變數(或說未解析的引用)將也會拋出語法錯誤:
"use strict";
delete i_dont_exist; // SyntaxError
未宣告的賦值跟嚴格模式下未宣告的變數所表現的行為類似(除了這次是引發引用錯誤而不是語法錯誤):
"use strict";
i_dont_exist = 1; // ReferenceError
正如你現在所明白的, 所有的限制多多少少是有道理的, 因為刪除變量, 函數聲明和參數會導致這麼多混亂. 與其靜默地忽略刪除操作, 嚴格模式採用了一種更加激進和更具描述性的措施.
總結:
這篇博文最後變得相當的長, 所以我不准備再去談論類似於用delete刪除數組對像或它的含義是什麼等. 你可以參考MDC文章對其專門的解釋(或者閱讀標準和自己做實驗).
這裡有一份對於JavaScript中刪除操作是如何工作的簡短的總結:
變數和函數宣告是活動物件或全域物件的屬性
屬性擁有一些特性, 這其中的DontDelete是決定這個屬性能否被刪除的那個特性.
在全域或函數程式碼中的變數和函數宣告總是建立帶有DontDelete特性的屬性.
函數參數總是活動物件的屬性, 並且帶有DontDelete.
在Eval程式碼中宣告的變數和函數總是創建不帶DontDelete的屬性.
新的屬性在建立時是沒有特性的(當然也沒有DontDelete).
宿主物件被允許自己決定如何對delete操作做出反應.
如果你想要對這裡所描述的東西更熟悉的話, 請參閱 ECMA-262 3rd edition specification.
我希望你能夠享受這篇文章, 並且學到一些新的東西. 歡迎提出任何問題, 建議或糾正.