Namespaces as Sugar (was: complexity tax)

[Brendan Eich]

On May 28, 2008, at 8:25 AM, Mark S. Miller wrote:

>> (For the record, I think
>> open namespaces as affecting lexical scope only would also remove  
>> the need
>> for first-class Name objects.)
>
> Yes, this is the clearest sign of how big an improvement. Variable
> lookup would once again be looking up a programmer-written identifier
> in a lexical environment to get a location, as opposed to the draft
> ES4 spec's double lookup (looking up an identifier to get a Name, and
> then looking up a Name to get a location).

Just for the record, Name objects arise in the reflection API in ES4,  
and they came up originally via the combination of for-in loop  
enumeration and namespaced property identifiers. So:

for (let name in obj)
   print(obj[name]);

should work given:

let obj = {ns::prop: 42};

and name will be bound to a Name instance with qualifier ns and  
identifier "prop". The disclosure of Name instances via for-in  
implies the ability to compute a property name by indexing an object  
with a Name instance (the disclosed instance).

We've since decided not to return Name instances from for-in's  
underlying iterator -- that is, non-public-qualified property  
identifiers are not enumerated. The motivation for obj[name] and the  
reflection APIs remains strong in ES4.

/be