Namespaces as Sugar (was: complexity tax)

[Maciej Stachowiak]

On May 26, 2008, at 11:39 PM, Brendan Eich wrote:

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

Actually, in this instance you were answering Mark's question: "What's  
the compelling need for a single object to simultaneously have  
properties defined in different namespaces?" Nothing to do with  
unqualified import per se (which I agree is important for top-level  
namespaces at least).

One can certainly question the need for any namespacing of object  
properties, let alone unqualified import of namespaces for such  
purposes.

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

Object property lookup need not be the same as scope chain lookup and  
it is ok by me if some global properties can only be accessed  
unqualified via the scope chain and not by direct global property  
access. The fact that the global namespace is also an object is cute  
but does not mean namespaces need to generalize beyond the global  
scope. For example, global unqualified namespace import could desugar  
(logically) into the injection of scope chain items instead of into a  
general property lookup mechanism.

Regards,
Maciej