ES4 draft: Object

Brendan Eich brendan at
Sat Mar 8 14:06:12 PST 2008

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)

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.


More information about the Es4-discuss mailing list