ES4 draft: Object

Brendan Eich brendan at
Tue Mar 11 10:32:27 PDT 2008

On Mar 10, 2008, at 6:43 PM, Yuh-Ruey Chen wrote:

> Ok, that cleared things up a bit. I didn't realize you were making a
> proposal and asking questions based off it :)

This is my fault for being unclear. I wrote:

Here's something I wrote a while ago (minor edits to update for
context) that attempts to subsume enumerability under namespacing:

and made a proposal. The "attempts to subsume" bit was not as clear  
as it could have been that I was making a novel proposal. Sorry about  

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

I can't think of one right now, but the thought comes from the

proposal, where you can reflect on names of types, at least. True,  
you can't iterate over all properties of an object, e.g., the expando  
example. But type names can be namespaced, and the Name object is  
used to reflect these.

If we end up making all namespaced properties non-enumerable, then we  
may want a property iterator that returns the names of all properties  
in a given object. Even if this is not in the standard, it's likely  
to be an extension. Or it could be added in the future.

The question of whether ES3+4 mixtures might not want enumerable ES3  
properties to appear to be in a predefined-in-ES4 namespace seems to  
me worth considering, at the limit as a future-proofing step.

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

No, the ticket is open and it needs more work. I wonder, though,  
whether Lars's example does not show how 'use namespace intrinsic' in  
that lexical scope (block) simply makes that open namespace take  
precedence. Since there is no explicitly opened public namespace in  
that scope, x.toString there resolves to x.intrinsic::toString.

The RI is buggy, it does not make const property initialisers  

 >> var x = { const toString: 37 }
       use namespace intrinsic
 >> >> >> >> [function Function]
 >> x.toString
 >> x.toString = 42
 >> x.toString
 >> delete x.toString
 >> x.toString
[function Function]

I filed on this RI bug.

We should work on this ticket more in the near term, I think.


More information about the Es4-discuss mailing list