Namespaces as Sugar (was: complexity tax)

[Brendan Eich]

On May 26, 2008, at 11:30 PM, Maciej Stachowiak wrote:

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

All true -- hence "different but related" -- the ability to cut  
across definitions with a single namespace in ES4 is a big one. But  
the point for this thread is the usability of unqualified import,  
which C++ supports and Mark's desugaring sketch does not, even at top  
level only.


>> 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?

Right.


> I'm not sure property namespacing is as critical to programming in  
> the large as top-level namespacing.

The top-level in ES is an object containing properties, so there's  
not much difference. Class objects, ad-hoc object, and the global  
object all benefit from cross-cutting namespaces in ES4, and in  
precursors such as AS3. Whether this is worth the cost is for another  
thread. Again my point is the importance of unqualified import for  
usability.

/be