ES4 draft: Object

Yuh-Ruey Chen maian330 at gmail.com
Mon Mar 10 16:43:34 PDT 2008


Brendan Eich wrote:
> On Mar 9, 2008, at 3:01 PM, Yuh-Ruey Chen wrote:
>
> > Brendan Eich wrote:
> >> 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?
>
> My reply was not meant to be an answer, but a question: should we  
> drop this dontenum-namespace idea because it will break ES3+ES4  
> mixtures where the ES4 code reflects on a property's namespace  
> qualifier by using a Name object?
>   

> > Does this included ES3-style prototype methods? And would it
> > be possible to init a fixture to be enumerable?
>
> In the sketch I mailed, you didn't see any mention of fixtures --  
> IIRC you asked about them in reply. Just to explain what my proposal  
> was aiming to do: It seems to me that if we have to add a magic bit  
> back into the skinny is-it-enumerable decision tree, we may as well  
> keep DontEnum.

> > And the RI does print
> > it, so I'm not sure what you're talking about.
>
> The RI is (a) not normative (nothing apart from ES3+fixes is yet),  
> (b) based on a DontEnum attribute model, not on my proposal. Not sure  
> why you thought I was talking about it. I was making a new proposal.
>   
Ok, that cleared things up a bit. I didn't realize you were making a 
proposal and asking questions based off it :) I thought you were 
mentioning how the RI was implemented today at the moment.

Can you elaborate on cases where "ES4 code does introspect via Name 
objects and is surprised to find "ES3" objects with qualified property 
names."? I can't think of any.

> > BTW, what exactly is a fixture?
>
> That's a good question, and it seems the answer is not in the wiki.  
> Trying the trac:
>
> http://bugs.ecmascript.org/ticket/233
>
> which references the overview document.
>
> In ES3 terms, a fixture is a property with the DontDelete attribute set.
>
> But there's more to it than that, for reasons expanded on in #233 to  
> do with namespace lookup and early binding. And there is another case  
> that Lars pointed out recently to do with dynamic classes, but I'll  
> avoid trying to summarize it except to say that a fixture is a fixed  
> property that can't be deleted or shadowed.
>   

Thanks, that's a good summary, though some of the commentary in the 
ticket was confusing (like lth's example - was x.toString decided to be 
ambiguous?).

> >> 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.
>
>  From your numbered steps above, step 3 must have been reached -- so  
> expando is in the public-public (null qualifier in Name object  
> reflection) namespace. Not in the class-C-public namespace. My  
> question is whether that is the right design choice.
>   

Are they any particular disadvantages that you can think of? Maybe 
another ES4 designer can chime in here.

BTW, a bit off topic: if a class is defined in a namespace, are the 
properties of that class also defined in that namespace (instead of just 
public/class-public)? Namespaces aren't clearly specified in the wiki or 
the overview, the tickets are unorganized, and the RI tends to barf when 
it comes to them. Ugh, I feel Apple's pain when they complain that they 
don't know where to start...

> > 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.
>
> Ok, I like that. I'm not arguing a side, just showing the choice.  
> There may be other cases, though, where a class-public property name  
> might want to be enumerable. In such a case the step 2 you wrote  
> would need to elaborate its "public" test. But again, my proposal was  
> about enumerability, independent of fixture-ness.
>
> /be
>   

Yeah, I asked whether it was possible to make a class-public property 
enumerable. And if so, I really would not want to do something silly 
like |public public var x|.

-Yuh-Ruey Chen



More information about the Es4-discuss mailing list