Namespaces as Sugar (was: complexity tax)

[Maciej Stachowiak]

On May 27, 2008, at 12:33 AM, Brendan Eich wrote:

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

I don't see how any of this argues for namespacing of properties on  
non-global objects, or why that case in particular requires  
unqualified import.

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

I don't see how your statement is responsive. Namespacing of non- 
object properties is poorly justified, in my opinion. Unqualified  
import of top-level names is well-justified. I don't see why you keep  
mixing the two together.

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

I don't disagree, the global object is reified so unlike activations  
it cannot be treated as just a convenient spec fiction and nor can it  
safely be removed.

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

Other languages with successful namespacing features don't have such a  
mechanism, so I am dubious of the goodness of these ideas. I am  
concerned that the namespace lookup algorithm for object property  
access is too complicated. It makes object property lookup depend on  
the set of open namespaces, which means obj.property may compile to  
entirely different code depending on the context, and it seems likely  
it will slow down property lookup when multiple namespaces are open  
but static type info is missing. If the only real justification is  
that it's a nice generalization, then I do not think it is worth the  
performance hit.

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

Is it really? Is there any other language where namespacing of the  
global namespace has led to namespacing at the sub-object level? C++,  
Java and Python all get by fine without namespacing of individual  
object properties.

The reason namespacing at top level is essential to programming in the  
large is that the global namespace is a shared resource and must be  
partitioned in controlled ways to avoid collision in a large system.  
But I do not see how this argument applies to classes or objects.

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

Nontheless, the global namespace is unique. There's no way to replace  
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.

The fact that the generalization seems to be unique to ES4 makes me  
dubious of its actual usefulness. If it has a performance cost, then  
the generalization seems like a dubious choice.

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

I'd love to hear the data. AS3 developers, can unqualified lookup of  
object properties on untyped references in the presence of property  
namespaces be as fast as when there aren't namespaces at all? If so,  
how? The most obvious way to do property lookup when there is no  
static type info is a hashtable lookup on each prototype chain entry,  
but I do not see an obvious way that a single hashtable lookup can  
look in multiple namespaces. I suspect the answer to this in AS3 is  
that if you want performance, you have to use type declarations.

Regards,
Maciej



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