Namespaces as Sugar (was: complexity tax)
mjs at apple.com
Tue May 27 08:45:06 PDT 2008
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:
>> 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
>> One can certainly question the need for any namespacing of object
>> properties, let alone unqualified import of namespaces for such
> 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
> 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es4-discuss