<br><br><div class="gmail_quote">On Mon, Aug 10, 2009 at 7:07 PM, Jeff Walden <span dir="ltr">&lt;<a href="mailto:jwalden%2Bes@mit.edu">jwalden+es@mit.edu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On 3.8.09 18:39 , Allen Wirfs-Brock wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Such a property would have pretty much the same effect as<br>
Object.defineProperty(obj, propname, { value: undefined})<br>
<br>
which creates a readonly, nonenumerable, nonconfigurable property whose value is undefined. There isn&#39;t much (if any, I need to look a litter deeper) real behavioral difference between such a data property and the equivalent accessor property except for what can be observed using Object.getOwnPropertyDescriptor.<br>

</blockquote>
<br></div>
See the original email; in some contexts attempting to set the property will result in a TypeError being thrown.  If it were simply equivalent to a data descriptor with value undefined, I probably would be much less concerned.<div class="im">
</div></blockquote><div><br>It is equivalent (modulo reflection) to a *non-writable* property with value undefined. Both throw when set from strict code. Neither throw when set from non-strict code.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I suppose we could put more conditions into [[DefineOwnProperty]] to reject<br>
accessors where both [[Get]] and [[Put]] are undefined. Do you think this<br>
is a significant issue?  Is it an error that is likely to be made?<br>
[[DefineOwnPropoerty]] is already fairly complicated so unless there is<br>
some real hazard to allowing such properties I&#39;m inclined to leave it as is.<br>
</blockquote>
<br></div>
It&#39;s the throw-on-set behavior that I&#39;m most worried about; I don&#39;t see how this particular flavor of property access is otherwise exposed, if this were to be forbidden.  As a consequence, I don&#39;t see much reason to require implementations to have to support the extra complexity (nor users to defend against it, as presumably they would to reduce confusion), not when it could be avoided by adding a single step to ToPropertyDescriptor:<br>

<br>
9.b. If desc.[[Get]] is undefined and desc.[[Set]] is undefined, then throw a TypeError exception.<br><font color="#888888">
<br>
Jeff</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
es5-discuss mailing list<br>
<a href="mailto:es5-discuss@mozilla.org" target="_blank">es5-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es5-discuss" target="_blank">https://mail.mozilla.org/listinfo/es5-discuss</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>    Cheers,<br>    --MarkM<br>