Attribute defaults for Object.defineProperty
brendan at mozilla.org
Sat Aug 23 13:39:08 PDT 2008
On Aug 22, 2008, at 11:53 AM, David-Sarah Hopwood wrote:
> Allen Wirfs-Brock wrote:
>> Michael Haufe [mailto:TNO at TheNewObjective.com] said:
>>>> Although I'd prefer to control Deletable separately from Fixed,
>> Using a single state to control deletability, attribute
>> mutability, and
>> property transformation/replacement is a compromise. There may be
>> situations where somebody would really like to control these
>> but it is probably a pretty limited use case.
> If you can set attribute mutability, then you can set the Delete
> If you can set the Delete attribute, then you can delete the property
> (and its current attributes).
> If you can delete the property, then you can recreate it with
> So, there is neither a security nor an expressiveness argument for
> any distinction between these rights. An argument for separating them
> would have to be based on convenience (but it seems less
> convenient, not
> more), or on preventing inadvertent, non-malicious changes, or
> on efficiency (but these operations are probably not common enough for
> that to be significant).
Agreed on all points. The prototype-based language Wheat started with
what looked like Unix owner/group/other permission bits, but the
nonsense or dangerous combinations were eliminated (if my memory
serves). We should not even flirt with this kind of false orthogonality.
That's why DontDelete was not a bad name in its day. Even in ES1 or
it (SpiderMonkey's name is "permanent").
It's not that "configurable" is bad, even if overlong. It is less
concrete in terms of what is controlled and why. Concrete names are
No "CanMod", though -- I was flashing back to 6BIT charsets on DEC 36-
bit processors ;-).
More information about the Es-discuss