On 3.8.09 18:39 , Allen Wirfs-Brock wrote:
Such a property would have pretty much the same effect as Object.defineProperty(obj, propname, { value: undefined})which creates a readonly, nonenumerable, nonconfigurable property whose value is undefined. There isn'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.
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.
I suppose we could put more conditions into [[DefineOwnProperty]] to reject accessors where both [[Get]] and [[Put]] are undefined. Do you think this is a significant issue? Is it an error that is likely to be made? [[DefineOwnPropoerty]] is already fairly complicated so unless there is some real hazard to allowing such properties I'm inclined to leave it as is.
It's the throw-on-set behavior that I'm most worried about; I don't see how this particular flavor of property access is otherwise exposed, if this were to be forbidden. As a consequence, I don'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: 9.b. If desc.[[Get]] is undefined and desc.[[Set]] is undefined, then throw a TypeError exception. Jeff _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
