Attribute defaults for Object.defineProperty

Brendan Eich brendan at
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] 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  
>> some
>> situations where somebody would really like to control these  
>> separately
>> but it is probably a pretty limited use case.
> If you can set attribute mutability, then you can set the Delete  
> attribute.
> 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  
> different
> attributes.
> So, there is neither a security nor an expressiveness argument for  
> making
> 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  
> possibly
> 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  
the prior JavaScript and JScript implementations had something like  
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  
generally better.

No "CanMod", though -- I was flashing back to 6BIT charsets on DEC 36- 
bit processors ;-).


More information about the Es-discuss mailing list