ES4 draft: Object

Brendan Eich brendan at mozilla.org
Fri Mar 7 15:01:20 PST 2008


On Mar 7, 2008, at 1:14 PM, Yuh-Ruey Chen wrote:

> Brendan Eich wrote:
>> 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.
>>
>
> Since enumerability only applies to for-in, how about the iterator
> namespace?

Good suggestion.

Here's something I wrote a while ago (minor edits to update for  
context) that attempts to subsume enumerability under namespacing:

If we say enumeration considers only public non-DontEnum properties,  
then DontEnum is always true for namespaced props. Mixing DontEnum  
magic into the

obj = {var dontDel: 42, const RO_AND_DD: "foo"}

idea is wrong -- these should be public and enumerable as other  
properties in object initialisers are, by default. But we are *this*  
close to eliminating an independent DontEnum attribute. The problem  
is how to express public + DontEnum.

Suppose we had a predefined, open namespace, say dontenum  (surely  
not the best name). If you write

obj = {dontenum::cant_see_me: 33}

then

for (i in obj) print(i)

shows nothing. But

obj.cant_see_me

works, because dontenum is always open. No more need for an  
orthogonal DontEnum attribute.

Instead of

obj.propertyIsEnumerable('i_want_to_hide', false)

users would just say

obj.dontenum::i_want_to_hide = ...

(typically obj is a prototype object and ... is a function). The  
"setter" mode (second boolean arg) of propertyIsEnumerable is ugly  
(everyone says so, no one denies). It's arguably hard to use (because  
verbose). It's racy for users who have to call it after creating a  
property (there's a window in which the property is enumerable -- not  
a threading race per se, more low-level bug habitat and needless  
worry). It's a burden on implementations that want immutable  
attributes for props.

On the down side, you can't just add

obj.dontenum::foo = function () {...}

to ES3 code that runs in ES3-only browsers, as you could with the  
propertyIsEnumerable hack. We should in any case design for the long  
run.

Note that any namespace would hide a property from enumeration;  
dontenum is not magic in that sense, only in that it is predefined  
and open by default (again, its name is a strawman).

For the long run, rationalizing dontenum via namespaces seems good to  
me.

> Object.prototype.iterator::setPropertyIsEnumerable(prop,
> enable). For consistency, you could also have
> Object.prototype.iterator::isPropertyEnumerable(prop) which  
> delegates to
> Object.prototype.isPropertyEnumerable(prop).

Clever relocation of "is" in the predicate names ;-). We're probably  
stuck with propertyIsEnumerable.

>> An alternative we've discussed, which Ian also brought up: add a
>> keyword for declaring DontEnum properties.
>
> This dontenum modifier can be used in addition to the method for
> convenience - it would make class declarations cleaner.

True of a namespace already, note.

> But despite that, I think dontenum is inelegant. Its only effect would
> be on the default enumerator, which is only one iterator, and AFAIK is
> not special at all. IMO, it isn't worth the bloat. If there was a  
> way to
> define such modifiers within script, then I think the dontenum  
> modifier
> would be nice. If such a capability is planned for a future ES  
> edition,
> then I think dontenum is fine.

What do you think of the only-public-properties-are-enumeable idea?

Obvious problem to be solved: public means several things: "no  
namespace" (backward compatible) vs. "public in this package or  
class". We should discuss this more.

/be




More information about the Es4-discuss mailing list