Namespaces as Sugar (was: complexity tax)

Maciej Stachowiak mjs at
Mon May 26 23:30:47 PDT 2008

On May 26, 2008, at 2:45 PM, Brendan Eich wrote:

> There are many use-cases. Consider the ES4 spec and Reference  
> Implementation, which segregate helper and informative methods from  
> normative ones in the public namespace in the built-in classes. The  
> Flex framework written in AS3 uses namespaces extensively. C++  
> programmers use a different but related kind of namespace all the  
> time.

C++ does not have namespacing of class members, or anything resembling  
it as far as I can tell. Namespaces in C++ are only a top-level  
construct, as in many other languages. Many good frameworks have been  
written in languages that only support top-level namespaces, not  
namespacing of properties or data members or whatever is the local  

> Waldemar's original proposal had namespaces as a cross-cutting  
> versioning tool:
> is worth a read if you haven't looked at his entire original  
> proposal (he mailed a tarball out recently).
> Perhaps more important than any of this, the existing practice among  
> JS (Ajax) libraries uses namespaces, but allows unqualified import  
> in various ways to populate more properties of the importing scope  
> object with shorthands. With this optional importing comes greater  
> risk of name collision. But it sure looks a lot like ES4's 'use  
> namespace MochiKit' or 'use namespace dojo'. It looks like  
> unqualified import.

But this is just unqualified import of a top-level namespace, not of  
property namespaces, right? I'm not sure property namespacing is as  
critical to programming in the large as top-level namespacing.

  - Maciej

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the Es4-discuss mailing list