On Mon, Aug 3, 2009 at 6:39 PM, Allen Wirfs-Brock <
[email protected]> wrote:
> Good one, I surprised that this has never come up before. I don't think
> there is anything intentional about the current design, it just fell out.
>
> 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.
>
> 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.
>
I vote to leave it as is. Even if this setting doesn't make particular sense
by itself, to prohibit it creates a special case. Symmetry and lack of
hazard suggests allowing it. And given the last date...
--
Cheers,
--MarkM
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
