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