Namespaces as Sugar (was: complexity tax)

Maciej Stachowiak mjs at
Tue May 27 23:46:32 PDT 2008

On May 27, 2008, at 12:18 PM, Mike Shaver wrote:

> 2008/5/27 Maciej Stachowiak <mjs at>:
>> It could save a lot of complexity, by not requiring any first-class  
>> support
>> for namespace lookup on arbitrary objects.
> Is the expectation then that having two lookup models, one for global
> objects and the other for non-global objects, going to provide less
> complexity?

My proposal is that there is one for lexical scope lookup along the  
scope chain (which considers open namespaces when binding unqualified  
names) and another for property lookup qualified to an object  
reference (which does not). Yes, I believe this will provide less  
complexity, because the scope chain and prototype chain algorithms are  
quite complex in the current proposal and not the same as each other.  
My rough proposal would greatly simplify the prototype chain algorithm  
and not make the scope chain algorithm any more complex (it may become  

> In a browser, "window" is the global object; would property lookup on
> "window" be namespaced when referenced as such?  When you have a
> handle to another window?  When you use |this.prop| in a global
> function?

My proposed answer to all of these would be no.

> If we have namespace-aware lookup, it seems to me that it would be
> less complex for implementors and script authors alike for it to
> always apply, rather than just for one magical object.

I think it would be simpler to limit the effect of namespaces to  
lexical bindings (where we know we can bind to the right name and  
namespace statically in any case of interest) and not have them affect  
object property lookup in general.


More information about the Es4-discuss mailing list