>> 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
_______________________________________________
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
