<div class="gmail_quote">2012/12/18 Allen Wirfs-Brock <span dir="ltr"><<a href="mailto:allen@wirfs-brock.com" target="_blank">allen@wirfs-brock.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><br><div><div class="im"><div>On Dec 18, 2012, at 9:08 AM, Brendan Eich wrote:</div><br><blockquote type="cite"><div>Mark S. Miller wrote:<br><blockquote type="cite">That could work, but because of its complexity, I'm leaning back towards the "configurable data property that refuses to be configured" approach. Is there a problem with that? It self-hosts fine.<br>
</blockquote><br>Certainly this is the simplest solution. It has a slight smell, but no worse than the others'!<br><br></div></blockquote><div><br></div></div><div>I'm really bothered by this concept. It seems to be saying:</div>
<div><br></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div>For my important use cases,  I must be able to depend upon the meaning of [[Configurable]]: false.  So implementation must take all measures necessary to ensure that meaning. However, I don't care about other use cases that might depend upon the meaning of [[Configurable]]: true.  I think its fine that  an implementation lies and says that an object is configurable when it really isn't.</div>
</div></blockquote><div><br></div>This really seems like a double standard. Integrity issue are important, and in some cases may need to be given special consideration, but we need to consider the full spectrum of use cases.<div>
<br></div><div>Regarding simplicity.  I don't really see it.</div><div><br></div><div>For example, we presumably still want global object bindings introduced via var to not be deletable via delete (unless they were introduced using eval).  How do we express the link between the semantic of var and delete if we can't use [[DefineOwnProperty]], [[GetOwnProperty]] and the [[Configurable]] attribute . Instead we have to define some new mechanism/state to establish this relationship  [1].<br>
</div></div></blockquote><div><br></div><div>I too find the solution of non-configurable data properties masquerading as configurable data properties bothersome. We have a mechanism in place for describing the behavior of ES5 properties, yet here is a case where we can't be honest about a property's real behavior. That smells.</div>
<div><br></div><div>The issue seems to be that there are two "access rights" to this data property: external clients are only allowed to read, but not write to the property (that is why it should really be reflected to clients as non-configurable). Some privileged code, however, is allowed to write to the property (that is why we cannot really make it non-configurable).</div>
<div><br></div><div>Implementing these access rights is easy to achieve using an accessor property, so it seems logical to turn this property into an accessor.</div><div><br></div><div>Why can't we make it a non-configurable accessor property? I don't understand the leak described by David in the OP.</div>
<div><br></div><div>Cheers,</div><div>Tom</div></div>