說(shuō)起js中的那些特性標(biāo)記，總覺得有些怪怪的，那為什么要說(shuō)到這個(gè)attribute，起源于對(duì)一個(gè)問(wèn)題的疑問(wèn)，我們都知道window對(duì)象其實(shí)就是

瀏覽器窗口的一個(gè)實(shí)例，既然是一個(gè)實(shí)例，那這個(gè)實(shí)例就應(yīng)該有“屬性”和“方法“，比如下面這樣：

我們平時(shí)都在使用function的時(shí)候，都會(huì)定義一些屬性，比如name，age等等，并且還可以對(duì)他們進(jìn)行delete，set和update操作。

那么下面問(wèn)題來(lái)了，既然我的person對(duì)象的name都可以動(dòng)態(tài)修改，按照這個(gè)道理的話，我也應(yīng)該可以修改window下的undefined值，然后就非常感興趣的想看一看。

結(jié)果還是可想而知，我并沒(méi)有成功修改undefined的值，那為什么會(huì)這樣呢？沒(méi)有道理呀，它又不是上一篇所說(shuō)的包裝類型，但我們不得不尊重結(jié)果，這就說(shuō)明js底層肯定是做了些什么才會(huì)導(dǎo)致這樣的結(jié)果，其實(shí)在底層js默認(rèn)用了Writable=false標(biāo)記才讓undefined屬性不可寫入，下面具體看看。

一：[Writable]特性

　　說(shuō)到屬性是否可寫，也許你會(huì)聯(lián)想到C#中的get/set訪問(wèn)器，又或者是readonly關(guān)鍵字，下面你肯定會(huì)感興趣我應(yīng)該怎么做到屬性的只讀操作。在js中你只要使用defineProperty方法就可以了。

 從上面的例子中可以看到三點(diǎn)好玩的東西：

<1>:  我使用了defineProperty方法將person.name變成了只讀字段，那有人要說(shuō)了，這明明是方法，怎么會(huì)是特性，特性在我的思維里面就是

         【xxx】模式，所以這就是js的不同之處，畢竟js沒(méi)有語(yǔ)法糖，所以定義特性只能是通過(guò)底層公開的方法來(lái)定義，也就是defineProperty。

<2>:  我在方法中不僅看到了writable，還有一個(gè)configurable，那這個(gè)是干什么的？其實(shí)這個(gè)就是基礎(chǔ)配置，告訴js引擎是否可以delete,update屬性，當(dāng)我把configurable設(shè)為false的時(shí)候，你就不可以delete p.Name了，因?yàn)檫@會(huì)是一個(gè)無(wú)效操作。  

看完了這些我覺的你應(yīng)該明白了，為什么undifined不能delete和update了。都是標(biāo)記做的怪，是不是覺得很有意思？

<3>： 下一個(gè)值得思考的問(wèn)題就是js引擎到底是怎么做到的，在C#里面也是有Atrribute，并且這個(gè)Atrribute被編譯器編譯后會(huì)記錄到元數(shù)據(jù)中，然后你就可以放心大膽的使用反射來(lái)獲取你的Atrribute中的任何值，比如說(shuō)Serializable序列化類，它就是告訴SerializableFormat怎么去反射讀取類，哪些字段可以序列化，哪些不可以，不可以的你需要用NonSerialized標(biāo)記。

從圖中可以看到IL中已經(jīng)記錄了Name為notserialized特性了，我們知道js中并沒(méi)有反射，所以突破口自然就在defineProperty方法里面，但是比較遺憾，我們看不到這個(gè)方法底層的源碼到底是怎么樣的，所以就不知道它對(duì)Name這個(gè)字段到底做了什么才可以動(dòng)態(tài)的導(dǎo)致它不可寫，只能根據(jù)理解去猜測(cè)js引擎可能會(huì)發(fā)生的行為。

最新評(píng)論