On Mar 8, 2008, at 1:16 PM, Yuh-Ruey Chen wrote: > Brendan Eich wrote: >>> - 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. > > But doesn't DontEnum still have to be there for ES3 objects? How else > would you prevent the enumeration of ES3 builtin methods, e.g. > Object.prototype.toString()? Or is there some more open namespace > magic > that I'm unware of?
ES3 code can't detect namespaces, so arguably shouldn't care if we were to implement DontEnum using an open namespace. But this could be a problem for mixed ES3 and ES4 scenarios where the ES4 code does introspect via Name objects and is surprised to find "ES3" objects with qualified property names. >>> 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. >> > > Well, I think the only overlap is that public-in-class-context methods > (or any method really) default to be non-public in terms of > enumerability Is that the right design? dynamic class C { public var fixture; function C() { this.expando = 42; } } for (var i in new C) intrinsic::print(i); wouldn't you expect to see "expando" printed? Is it printed because the default namespace for expando is the public-default one? I believe it is not, in the current proposal and the RI. Rather, each class or package gets a nonce-named public namespace, different from every other such per-class or per-package public. IIRC package trumps class -- classes within a package share the package's nonce-named public namespace (Jeff, Lars, please correct me if I'm wrong). > While we're on the topic of namespaces, I read in the ES4 overview: > "In > addition, the names internal, public, protected, and private denote > namespace values, but the values depend on the context of the use." As > the wiki doesn't talk about this, and the online spec is > inaccessible/outdated, can you elaborate on this? I wonder if > 'private' > could be used somehow for enumerability. This is the entire issue. See above and let me know if that's unclear. /be _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss