Namespaces as Sugar (was: complexity tax)
brendan at mozilla.org
Tue May 27 00:33:10 PDT 2008
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es4-discuss