Namespaces as Sugar (was: complexity tax)

[Brendan Eich]

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

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


> If I misunderstood your question, and if it actually wasn't snarky,
> then I apologize and withdraw the snarkiness of my answer.

Thanks.


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

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

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

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  
versioning tool:

http://www.mozilla.org/js/language/old-js2/js20/rationale/ 
versioning.html

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

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.mozilla.org/pipermail/es-discuss/attachments/20080526/9f2b0677/attachment-0002.html