ES4 draft: Object

Lars Hansen lhansen at adobe.com
Thu Mar 6 17:30:03 PST 2008


> -----Original Message-----
> From: es4-discuss-bounces at mozilla.org 
> [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of Brendan Eich
> Sent: 5. mars 2008 19:19
> To: Erik Arvidsson
> Cc: es4-discuss at mozilla.org es4-discuss
> Subject: Re: ES4 draft: Object
> 
> 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.

Right, it comes up from time to time.  Using __ES4__ here would set
a precedent that might not be the best.

> 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!"}

Not filed in the Trac to my knowledge, but not forgotten.

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

The text of E262-3 does not reveal anything unusual about the
Error objects, as far as I can see.

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

Also, a declarative form is of uncertain value, since the object
that receives the new property whose attr must be set, already
exists.  Thus if there is some sort of new keyword form it needs
to be associated with the assignment somehow.

--lars



More information about the Es4-discuss mailing list