ES4 draft: Object

Brendan Eich brendan at
Sun Mar 9 19:16:11 PDT 2008

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?

> Let me get this straight. The rules of enumerability are:
> 1) If a property is a fixture, it's not enumerable.

I never said any such thing. My hope was to avoid special cases and  
use only a predefined, opened-by-definition namespace.

> BTW, what exactly is a fixture?

That's a good question, and it seems the answer is not in the wiki.  
Trying the trac:

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.

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

> 2) If a property is not in the public namespace, it's not enumerable.

Right, I said that ;-).

> 3) Otherwise, it is enumerable.
> 4) No hidden DontEnum attribute.

4 is more of an aside than a step, but yeah, that's it :-).

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

My proposal had no mention of fixture "voodoo" -- you cast that  
spell ;-).

Notice that most DontEnum (almost all) properties defined by ES3 are  
not fixtures because they are not DontDelete. IIRC only a few such as  
standard prototype's constructor properties are DontDelete.

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

(Not in my proposal)

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

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

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


More information about the Es4-discuss mailing list