Namespaces as Sugar (was: complexity tax)

[Mark S. Miller]

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

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
> obj["ns/prop"].

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


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


> Or make an alternative proposal.
> All I am suggesting is that any solution (a) not reinterpret existing
> property names, and (b) support unqualified import in osteele's sense of the
> phrase.


Earlier I said

> So, although I don't find any of these use-cases compelling, I'd agree
> that #b is at least a real problem, and is the most plausible of the
> arguments for some additional support in a future JavaScript. My next
> message, if I get to it, will be "Namespaces as Sugar". If you agree
> with me that #b is better avoided than solved, feel free to skip it.

so I hope I've been clear that my favorite alternate proposal is to
avoid adding any namespace mechanism to EcmaScript at all. This would
clearly satisfy your (a) request above. Depending on what
"reinterpret" means, I argue that Namespaces-as-Sugar also satisfies
(a). It just provides some conveniences for saying what can already be
said more awkwardly.

As for your (b), I fail to see why it's good. Remember, we are talking
about property names here, not module linkage! 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?

-- 
    Cheers,
    --MarkM