Namespaces as Sugar (was: complexity tax)
mjs at apple.com
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es4-discuss