On Aug 22, 2008, at 11:53 AM, David-Sarah Hopwood wrote: > Allen Wirfs-Brock wrote: >> Michael Haufe [mailto:[EMAIL PROTECTED] 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 ;-). /be _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
