Controlling DontEnum (was: ES4 draft: Object)

Kris Zyp kris at sitepen.com
Tue Mar 11 20:32:13 PDT 2008


>> I've read mention of the weirdness of the timing window between the
>> property definition and it's marking as non-enumerable.  That combined
>> with the above observation makes me wonder if this should really be
>> obj.__setNonEnumerableProperty__(name, value);
>
> +1
I like it too. Any chance that by setting the attribute at the same time of 
setting the property value, we could resurrect the possibility of setting 
other attributes as well (with a single method):

Object.prototype.__setPropertyWithAttributes__(name, value, dontEnum: 
boolean, readOnly: boolean, dontDelete: boolean);

And various proposed syntax like:
obj = {dontenum a: 1, const b: 2, var c: 3};

could be written:
obj = {};
obj.__setPropertyWithAttributes__("a",1,true); // property a is not 
enumerable

obj.__setPropertyWithAttributes__("b",2,false,true); // property b is 
readonly

obj.__setPropertyWithAttributes__("c",3,false,false,true); // propery c is 
permanent

I wonder if readonly and dontdelete are other attributes where there might 
be benefits derived from trusted code (regular ES3/4) being able to control, 
and untrusted code (ses, caja) not being able to control. I can't think of 
what those benefits might be, maybe another question for Mark or Doug to 
think on.

Kris 




More information about the Es4-discuss mailing list