ES4 draft: Object

Brendan Eich brendan at mozilla.org
Fri Mar 7 18:48:59 PST 2008


On Mar 7, 2008, at 6:30 PM, Yuh-Ruey Chen wrote:

> Interesting and clever proposal. Some thoughts:
>
> - It would become harder to change the enumerability of a property
> (compared to a enumerability method): |obj.prop=obj.dontenum::prop;
> delete obj.dontenum::prop;| That said, I'm not sure there are many use
> cases that involving changing enumerability after the prop's
> enumerability is initially defined.

There are no valid use-cases IMO -- what Prototype et al. want is a  
way to create DontEnum properties on (standard or not) prototype  
objects _ab initio_.

> - If you add setPropertyIsEnumerable(), how would that interact with
> this? Would it change the namespace as described above, or just toggle
> the hidden DontEnum attribute?

I would withdraw that proposed extension (under any API) in favor of  
this one.

> - Users may think this dontenum namespace is magical and yet another
> thing to keep in mind, when it really just relies on the namespace  
> trick
> you mentioned. With the introduction of classes and namespaces, the
> rules of enumerability are already more complex, so this adds to the
> cognitive load slightly.

Slightly, but it takes away the magic DontEnum attribute, formerly  
hogged by the specification and magic predefined objects.

> BTW, if setPropertyIsEnumerable() is added,
> would it be possible to make fixtures enumerable? Enumerability is
> orthogonal to static analysis (which fixtures are meant to help with),
> so I don't see why not.

This gets to the heart of the public vs. public-in-context-of-class- 
or-package issue. We need to sort this out to find out exactly how  
orthogonal enumerability is, as well as decide how flexible it should  
be.

> - The name sucks :p

Indeed. How about 'hidden' or 'nonEnumerable'?

/be




More information about the Es4-discuss mailing list