ES4 draft: Object

Yuh-Ruey Chen maian330 at
Sun Mar 9 15:01:09 PDT 2008

Brendan Eich wrote:
> On Mar 8, 2008, at 1:16 PM, Yuh-Ruey Chen wrote:
> > 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.

I'm talking about how the enumerability (or lack thereof) of 
Object.prototype.* are determined. Or are prototype methods also not 
enumerable by default like fixtures?

Let me get this straight. The rules of enumerability are:
1) If a property is a fixture, it's not enumerable. BTW, what exactly is 
a fixture? Does this included ES3-style prototype methods? And would it 
be possible to init a fixture to be enumerable?
2) If a property is not in the public namespace, it's not enumerable.
3) Otherwise, it is enumerable.
4) No hidden DontEnum attribute.

Are we trying to simplify this to the last three rules using some 
namespace voodoo to handle the fixture rule? I'm confused.

> > 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).

I meant non-expando vars and methods defined within the class, whatever 
the terminology is used (I see 'fixture' thrown around everywhere), are 
not enumerable. So yes, expando should be printed. And the RI does print 
it, so I'm not sure what you're talking about. Are you saying that each 
property is defined in a "class-specific public" namespace, and 
therefore does not get enumerated? I would say that expando properties 
should be defined in the "global public" namespace, so that they would 
be enumerated.

-Yuh-Ruey Chen

More information about the Es4-discuss mailing list