Namespaces as Sugar (was: complexity tax)

[Brendan Eich]

On May 28, 2008, at 12:48 AM, Maciej Stachowiak wrote:

> On May 27, 2008, at 1:07 PM, Brendan Eich wrote:
>
>> I forgot one of the main use-case for 4, one you've expressed  
>> interest in already: 'use namespace intrinsic'. Without (4), this  
>> does not allow early binding for s.charAt(i) given var s:string to  
>> string.prototype.intrinsic::charAt.
>
> Yeah, but you can't early bind this anyway if s lacks a type  
> annotation (or you otherwise have inferred that s is of string  
> type). In fact if you can't infer the type of s then you get worse  
> performance than if you hadn't opened any namespaces.


That depends on the implementation, but let's say it's true. You  
still get the better-typed fixtures (the string class's  
intrinsic::charAt method) instead of possibly overridden prototype  
properties.

The 'use namespace intrinsic' design for early binding grew out of  
the "compact profile" of ES3, which is a dead letter on the web  
because it's overtly incompatible (the spec is short enough to read  
in a few minutes: http://www.ecma-international.org/publications/ 
standards/Ecma-327.htm). A pragma for prioritizing fixed methods with  
stricter type signatures was prototyped by the strict mode in AS3.  
During collaborative ES4 development in TC39 TG1, we synthesized  
aspects of these precursors into 'use namespace intrinsic'.

This design is implemented in the ES4 RI, and it will probably be in  
a couple of practical open source implementations this year. We want  
to get user as well as implementor feedback.


> But you do have my number - I like the potential for early binding  
> both for program understandability and performance. I would love to  
> see a way to make it possible without at the same time making  
> property lookup in the face of unknown types slower. I will think  
> about it myself but perhaps someone else will come up with  
> something clever.

Great. In the mean time, we'll be working on clever solutions to  
speed up all property lookups, even with open namespaces. Maybe we'll  
convince you that cleverness is better applied by implementors to  
enable programmers who benefit from new things like cross-cutting  
intrinsic, debugging, version2, etc. namespaces.


> As for my motherhood & apple pie lecture, it is based on experience  
> with a working on a high-performance production-quality JavaScript  
> implementation. We managed to pretty much rewrite the core  
> interpreter for a significant performance boost in about two  
> months, and that was struggling against the existing complexity of  
> de facto JavaScript (ES3 + some Mozilla extensions). Along the way  
> we found some correctness bugs that exist in pretty much all  
> existing implementations (sequencing considerations in the face of  
> exceptions for instance). If the language were much more complex,  
> then it would be much harder to make architectural changes of the  
> implementation.

Two months. Sorry, but if it took you three or four months to do that  
and also include namespace optimizations, but the benefit to the  
great many JS or would-be ES4 programmers were enough, then why  
wouldn't you take the extra month or three?

Given the needs of the many and the scale of the web, I continue to  
believe that the main argument should be about maximizing usable  
utility for programmers writing in the new version of the language --  
only secondarily about hardships for implementors who make the big  
bucks making JS go fast :-/.

/be