namespaces and expression-qualified names

Brendan Eich brendan at
Thu Mar 20 23:44:58 PDT 2008

On Mar 20, 2008, at 11:31 PM, Jon Zeppieri wrote:

> On 3/21/08, Jon Zeppieri <jaz at> wrote:
>> Are namespaces (and I'm not referring to the reflected objects  
>> here)...
> Except I am referring to those, aren't I?

What's a value? Types too have constant binding forms but runtime  
value status. Namespaces and types may be useful at runtime, e.g. for  
capability-like protection (you can read what you can name) and  

The choices so far for types have ruled out runtime type annotations,  
in order to support the optional strict mode's static checker and  
keep it efficient and fairly conventional. But we've talked about  
alternatives such as contracts (a la PLT Scheme). This goes way back.  
See, e.g. 

>>> namespace ns1
>>> ns1 is Namespace
> true
> So, at runtime, ns1 is the reflected object.  That leaves that matter
> of expression-qualified names...

I wrote in reply to Mark that ES4's namespaces did not derive from  
E4X (ECMA-357). More the reverse, although of course XML namespaces  
were primary. SpiderMonkey supports E4X and runtime namespace  

js> ns = new Namespace("hi")
js> o = {}
[object Object]
js> o.ns::p = 42
js> o.ns::p
js> id="p"  // assume compiler can't propagate the constant "p"
js> o.ns::[id]

This is all in Firefox 1.5-3.

I believe the intention among the core ES4 group over the last couple  
of years has been to support runtime qualifiers in ES4, as well. JS  
has computed property names since day 1: o[id] to access o.p. An  
optional strict mode can't reason about these, but they aren't the  
only loophole (eval, with, global non-fixtures). Why rule out runtime- 
computed qualified names (with either part computed at runtime)?

Other core ES4 group members should chime in here.


More information about the Es4-discuss mailing list