Allen.Wirfs-Brock at microsoft.com
Sun Nov 16 10:25:53 PST 2008
In addition to David-Sarah's points we hoped that repurposing the DontDelete attribute as [[Configurable]] would ease implementation level transition from ES3 to ES3.1. Assuming a implementation already has single bit encodings to represent DontDelete, DontEnum, and ReadOnly is may be less disruptive to reinterpreted the meaning of one of the bits than to find space to encode additional attributes.
I believe that the rationale for Configurable is also covered in http://wiki.ecmascript.org/lib/exe/fetch.php?id=es3.1%3Aes3.1_proposal_working_draft&cache=cache&media=es3.1:rationale_for_es3_1_static_object_methodsaug26.doc
>From: es-discuss-bounces at mozilla.org [mailto:es-discuss-
>bounces at mozilla.org] On Behalf Of David-Sarah Hopwood
>Sent: Sunday, November 16, 2008 7:09 AM
>To: es-discuss at mozilla.org; es3.x-discuss at mozilla.org
>Subject: Re: Kona [[Configurable]]
>Peter Michaux wrote:
>>>From 8.6.1, Table 2
>> If true, attempts to delete the property, change the property to a
>> data property, or change its attributes will succeed.
>> This looks like at least three orthogonal properties to me.
>> If true, attempts to delete the property will succeed.
>> If true, attempts to change the property to a data property will
>> If true, attempts to change its attributes will succeed.
>> Why have these three things been lumped together? It seems like it
>> would only be luck that these three seemingly orthogonal properties
>> would always change in unison. For example, for a non-deletable
>> property, why couldn't the enumerability of that property be changed?
>If you can set attribute mutability ([[ReAttributable]] above), then
>you can set the [[Deletable]] attribute.
>If you can set the [[Deletable]] attribute, then you can delete the
>and its current attributes.
>If you can delete the property, then you can recreate it with different
>attributes (implying [[RePropertyTypeable]] and [[ReAttributable]]).
>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 possibly
>on efficiency (but these operations are probably not common enough for
>that to be significant).
>Es-discuss mailing list
>Es-discuss at mozilla.org
More information about the Es-discuss