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.
/be
_______________________________________________
Es4-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es4-discuss
