Namespaces as Sugar (was: complexity tax)
brendan at mozilla.org
Mon May 26 14:45:48 PDT 2008
On May 26, 2008, at 12:05 PM, Mark S. Miller wrote:
> On Mon, May 26, 2008 at 11:29 AM, Brendan Eich
> <brendan at mozilla.org> wrote:
>> On May 26, 2008, at 10:34 AM, Mark S. Miller wrote:
>>> On Mon, May 26, 2008 at 10:22 AM, Brendan Eich <brendan at mozilla.org>
>>>> Why not give them both better syntax and better semantics?
>>> A wonderful idea! I eagerly await such a proposal.
>> Was that mere snarkiness?
> It was a snarky answer to what I perceived to be a snarky question. Of
> course we want "better". The whole argument is about which direction
> is better. Your question assumes your conclusion.
Not quite. My point was not snarky, and it did not assume a
conclusion -- it questioned your premise: "Rather than invent new
semantic concepts ...". You propose new syntax that desugars to
existing semantics. I am asking: is there a non-trivial benefit in
extending semantics too? Why not extend semantics too?
The answer turns, I think, on usability of namespaces, in particular
on whether "unqualified import" is important.
It may be hard to argue about usability except by pointing to other
languages. Hence my references to XML namespaces, which pretty
clearly suffer from lack of unqualified import.
It may be that you and I differ again in preferring ES3.1 vs. ES4
premises, and one of the ES4 premises you reject is "unqualified
import is important for usability" (assuming premises justifying
adding namespaces in the first place).
In that case, it would still help if you had an argument based on ES4
premises that led to a simpler ES4. But it would be sillly to repeat
ES3 premises as disqualifying a part of ES4, since they're different
evolutions of ES3 with different design goals based on different
> If I misunderstood your question, and if it actually wasn't snarky,
> then I apologize and withdraw the snarkiness of my answer.
>> The ES4 proposal has unqualified import. It has backward
>> compatibility in
>> the sense that it does not change the interpretation of obj
>> ["ns::prop"] or
> Depends what you mean by "change the interpretation". IIUC, ES4 would
> change the interpretation of the second of these to
> obj[public::"ns/prop"] (or it would if string literals were allowed to
> the right of a colon).
It would be something like obj.public::["ns/prop"], but the point is
that this ES4 spelling makes no change from ES3 terms (obj["ns/
prop"]), where every property specified by ES3 or created by an ES3
programmer is in the public (compatibility) namespace. It's
equivalent syntax, it parses to the same post-definition-phase AST node.
> Namespaces-as-Sugar doesn't expand the set of
> mentionable property names, but it allows some to be said in a
> syntactically more convenient fashion. This doesn't change the meaning
> of obj["ns/prop"]. It just allows the syntax obj.ns::prop to mean the
> same thing.
Oh, I see. Two issues apart from usability:
1. Is it compatible with all relevant Ecma standards? It is not with
ECMA-357, E4X. Breaking compatibility with another Ecma standard, one
implemented in at least three common implementations (SpiderMonkey,
Rhino, ActionScript 3 in Flash 9 and higher), may be a cost worth
paying. I'm not convinced, and Ecma/ISO folks may frown on such an
2. Is it compatible or safe (integrity-wise) if you allow unqualified
import? Once you allow the identifier expression prop to denote
obj.ns::prop in some ns-importing context where obj is on the scope
chain, it seems to me you've allowed arbitrary ES3 code to inject
identifiers into ES4 namespaces. Consider the case where obj is the
In ES4, a namespace (a first class object) can be hidden, internal to
a compilation unit (file or script source). It is therefore not
possible in ES4/ES3 mixed embeddings for ES3 to inject names into any
old namespace, just by prefixing "ns/" to the property identifier.
This is an important integrity property.
>> If it has other problems (it surely does -- we're working on
>> specifying it fully, and implementing it in the RI -- both of
>> which help
>> find problems), then please point them out.
> Section 4.7 "Name Resolution" of the draft spec document goes on for
> nine pages. Do you consider this a problem?
I already replied in an earlier thread: "I agree with you that
namespaces add more complexity than classes alone".
But for the record, no: high (or merely moderate) draft-spec page
counts do not constitute a problem by themselves. In particular, a
finished language spec may need many pages to specify something
subtle, which has the beneficial effect of *reducing* programmer
burden, including cognitive load or "complexity." Someone has to pay
for a solution to a problem such as namespacing. There's no free
lunch. Currently ES puts almost all the burden on the programmer.
Also, the spec draft pages currently dedicated to name lookup seem to
me ripe for reduction in size. Maybe not to one page, but we'll see.
It's too early, besides being inconclusive, to bean-count spec pages
and score accordingly.
> As for your (b), I fail to see why it's good. Remember, we are talking
> about property names here, not module linkage!
Who said anything about modules? Oliver Steele's "import" usage
should not mislead. We're talking about how to use namespaces without
requiring every reference to a namespace-qualified name to be
explicitly prefixed by a qualifier. Namespaces cut across compilation
unit, class, and object boundaries in ES4 as proposed.
> What's the compelling
> need for a single object to simultaneously have properties defined in
> different namespaces? How would those properties come to be added to
> that object? I just don't get it. Am I missing something?
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.
Waldemar's original proposal had namespaces as a cross-cutting
is worth a read if you haven't looked at his entire original proposal
(he mailed a tarball out recently).
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Es4-discuss