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 _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
