Namespaces as Sugar (was: complexity tax)

[Brendan Eich]

On May 27, 2008, at 12:00 AM, Maciej Stachowiak wrote:

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

I wrote "There are many use-cases" and talked about two: name  
collision avoidance, unqualified import. In the course of this, I  
cited C++. C++ doesn't have "objects as scopes" or "properties", but  
if it did, then the top-level could be a single object with  
properties in several namespaces. And C++ does support  
"properties" (globals) with the same unqualified identifier but  
different namespaces -- and C++ does support unqualified import.

So C++ namespaces are not the same as ES4 namespaces -- I never said  
they were (more the reverse)! The points, plural, that I was making  
(yes, I was going beyond Mark's question -- I'm not a deposed witness  
being interrogated here, so excuse me for talking about more than  
what was asked) apply to both C++ and ES4.


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

I hope so. I'd rather have someone question unqualified import than  
implicitly dismiss it, which is what seems to be happening.


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

Fundamental to JS, impossible to change in ES3-compatible areas, and  
-- here we may disagree -- unwise to turn away from for future  
additions to ES3.


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

That's an interesting idea, although we use namespace qualification  
along the prototype chain all over the place in ES4, and for what  
seem like good reasons.

ES (any version) has objects as scopes, as well as prototypes. It's  
hard to keep the gander -- objects below the top level, or on the  
prototype chain -- from wanting the same sauce that the goose -- the  
global object -- is trying to hog all to itself.

Objects and their properties move around over time, both along the  
scope and prototype chains. Real web apps I've studied from a low- 
level actually take advantage of the ability to "pun" objects along  
both chains (including the global object).

Also, JS hackers often prototype in global code and then push things  
down into closures or sub-objects.

Then there is the namespaces-for-versioning idea, which wants to cut  
across classes as well as global objects.

I'm not going to belabor the general argument for uniformity that  
favors namespaces as qualifiers usable in all objects that can reach  
the given namespace by reference (if it's opaque) or use it by name  
(if transparent), because it is a generalization. We have many and  
specific use-cases in ES4 (intrinsic, iterator, helper, informative  
come to mind) for sub-global namespacing. We've generalized, instead  
of making ad-hoc or particular and restrictive solutions.

Is the cost too high? I think that depends on how the name lookup  
algorithm works on real-world code. AS3 developers have data to  
share. Let's get into that.

/be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20080527/339ffbdd/attachment-0002.html