Namespaces as Sugar (was: complexity tax)

[Maciej Stachowiak]

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

> Waldemar's original proposal had namespaces as a cross-cutting  
> versioning tool:
>
> http://www.mozilla.org/js/language/old-js2/js20/rationale/versioning.html
>
> 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...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20080526/34a4f319/attachment-0002.html