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 >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:es-discuss- >[EMAIL PROTECTED] On Behalf Of David-Sarah Hopwood >Sent: Sunday, November 16, 2008 7:09 AM >To: es-discuss@mozilla.org; [EMAIL PROTECTED] >Subject: Re: Kona [[Configurable]] > >Peter Michaux wrote: >>>From 8.6.1, Table 2 >> >> [[Configurable]] >> 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. >> >> [[Deletable]] >> If true, attempts to delete the property will succeed. >> >> [[RePropertyTypeable]] >> If true, attempts to change the property to a data property will >succeed. >> >> [[ReAttributable]] >> 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 >property >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 >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). > >-- >David-Sarah Hopwood >_______________________________________________ >Es-discuss mailing list >Es-discuss@mozilla.org >https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
