ES4 draft: Object
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
> - Users may think this dontenum namespace is magical and yet another
> thing to keep in mind, when it really just relies on the namespace
> 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
> - The name sucks :p
Indeed. How about 'hidden' or 'nonEnumerable'?
More information about the Es4-discuss