Controlling DontEnum (was: ES4 draft: Object)

Brendan Eich brendan at mozilla.org
Tue Mar 11 22:01:13 PDT 2008


On Mar 11, 2008, at 8:32 PM, Kris Zyp wrote:

> 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);

Only if you cannot change an existing properties attribute, or delete  
an existing property and create a new one with the same name. Those  
cases would have to fail. A false return is not a fail-stop  
condition, so an exception might be better. Mark probably has  
thoughts on this -- he referred to "defensive consistency" as defined  
in his thesis when we discussed the silence-is-deadly ES1-era  
handling of assignment to read-only properties, and the almost  
useless boolean result of the delete operator.

> 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.

You can't implement JS in JS without something like this. Narcissus  
has almost exactly what you describe here, only SpiderMonkey js  
shells built with NARCISSUS=1:

http://lxr.mozilla.org/mozilla/search?string=__defineProperty__

But this, as its name suggests, is unsafe: it will redefine a  
property, clobbering any existing attributes and value. And yeah, the  
lack of named parameters hurts call-site readability.

/be



More information about the Es4-discuss mailing list