On 13/03/2008, Lars Hansen <[EMAIL PROTECTED]> wrote: > Since our method is creating a new property and not setting > one, I suggest __createProperty__ as the most appropriate > name, so I'm going to use that below.
Sounds perfectly reasonable to me. > I still think it may be right that properties in non-public > namespaces should not be enumerated, but I also think that's > orthogonal to the discussion that's going on here, about > dynamic properties and their attributes. We've pretty much > decided (ticket #233 has some of the discussion) that for > future compatibility there ought to be a difference between > fixture properties and DontDelete "dynamic" properties. So > dynamic properties have at least one attribute bit like they > do in ES3 (for deletability). Consequently, they might as > well have all the ES3 bits: for enumerability and writability. For ES4, shouldn't this function also take a type binding? > Ergo, let's assume that we are not finessing more than we > have to, and dynamic properties have all these attribute bits. > I don't know why __createProperty__ should not be able to > set all of these. Neither can I. > (They're not independent, ReadOnly implies DontDelete.) > > __createProperty__ should throw an exception (TypeError?) if > the property already exists on the object or would shadow a > ReadOnly property, a la [[CanPut]], or if the object is not > dynamic. It should probably throw an exception if its > arguments are not consistent (ReadOnly && !DontDelete). If ReadOnly is specified, is there even a reason to look at DontDelete? > Pesonally I like the strings approach, but the only interface > among these four that has good compile-time checking is the > first one, so I'm going to propose that we use that one, > with dontEnum as the first flag, dontDelete as > the second, and readOnly as the third (based on a guess about > the frequency of use). Thus on Object.prototype and as an > intrinsic propety on Object instances: > > function __createProperty__(name:EnumerableId, > dontEnum:boolean=false, > dontDelete:boolean=false, > readOnly:boolean=false): void ReadOnly would need to be instanciated at the same time, no? And you probably want to be able to specify a type binding for ES4. > * The above does not preclude complementary declarative > mechanisms in ES4 (but not in ES3.1 obviously) Good to hear, because I still want to see something that can be used in object literals and property declarations. -- David "liorean" Andersson _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
