Namespaces as Sugar (was: complexity tax)
brendan at mozilla.org
Wed May 28 12:53:38 PDT 2008
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
> 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
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
> 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
> 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
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 :-/.
More information about the Es4-discuss