ES4 draft: Object

Brendan Eich brendan at
Wed Mar 5 19:19:00 PST 2008

Hixie argued strongly on IRC today for something that does not  
overload set with get -- this seems to be the heart of the "ugly"  
objection, although there are other things to dislike about both the  
form and function of propertyIsEnumerable (it does not consider  
prototypes, as for-in does; its name is overlong and it violates  
standard naming conventions for "is" method).

To avoid injecting a public name into Object.prototype, we could put  
a new "setPropertyIsEnumerable" (yechh) name in the __ES4__  
namespace. Then there's no breaking change. We do this already, of  
course, but not for property attribute fiddling.

An alternative we've discussed, which Ian also brought up: add a  
keyword for declaring DontEnum properties. It turns out the full  
combination of property attributes is not interesting. We have const  
for DontDelete+ReadOnly (ReadOnly without DontDelete guarantees  
nothing, is worthless) including in object initialisers:

obj = {const PI: 22/7}; // Ohio legislature once so legislated

We have (I hope it got filed) a ticket asking for DontDelete by  
itself via var in object initialisers:

obj = {var x: "mutate me, but you can't delete me!"}

DontEnum is orthogonal but clear by default for binding and assigning  
forms in ES3. It is set for "built-ins", generally speaking (some odd  
exceptions that I recall in the Error objects -- I was not around  
much for ES3, although I did the work in Netscape 4 that fed into it!).

So, rather than add an ugly "dontenum" keyword that would be seldom  
used, the group preferred a built-in method. But this may have been a  
minor mistake. For those interested, here's the full rationale as I  
remember it:

Besides avoiding adding anything with a plain name to  
Object.prototype, the appeal (if you can call it that) of extending  
propertyIsEnumerable with an optional second argument lies in the  
ability to call it with two arguments in an ES3 implementation. That  
won't have any effect, but it won't break callin code in ES3  
implementations either.

Thus Ajax libraries such as Prototype (if it still does this) could  
add calls to turn off enumerability of properties the library sets on  
standard prototypes, and then those properties would disappear from  
for-in loop enumerations in ES4 implementations.

Mainly we do not expect the ability to turn off enumeration of a  
given property to be a frequent programmer task, so we did not want  
to add a new method if we could piggy-back on an existing  
Object.prototype method. For library authors, we wanted something  
that failed soft in ES3. And yeah, we knew it was "ugly", but  
propertyIsEnumerable is already ugly already.


More information about the Es4-discuss mailing list