On May 27, 2008, at 1:07 PM, Brendan Eich wrote: > On May 27, 2008, at 11:42 AM, Maciej Stachowiak wrote: > >> On May 27, 2008, at 11:00 AM, Brendan Eich wrote: >>> What's at issue is whether and why unqualified import matters in >>> any object, even the global object only, since the NAS proposal >>> did not allow unqualified import even at global level, and the use- >>> case for unqualified import was dismissed as not compelling. >> >> There's really 4 separable issues: >> >> 1) Namespacing of names at global scope (via lexically scoped >> reference). >> 2) Unqualified import of names into global scope. >> 3) Namespacing of arbitrary object properties. >> 4) Unqualified import of namespaces for arbitrary object properties. >> >> I would claim 1 and 2 are essential, 3 can be done by convention in >> the absence of 4 (a la the NAS proposal) and 4 is unnecessary and >> harmful to performance. > > > Thanks, this is helpful, since the argument you joined was about (2) > and/or (4) -- there is no unqualified import in the NAS sketch. > > 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. Plus lookup of any property names that couldn't have been early bound at all if the exact type had been inferred is likely to suffer. So I'm not sure any more it is good to encourage adding "use namespace intrinsic" to otherwise unchanged ES3 programs. 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. 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. I believe this is a quality worth preserving. Well-engineered tight code can sometimes beat the fanciest of rocket science optimizing implementations simply because it is easier to understand and therefore measure and optimize. (To some extent, this applies less to pure syntactic sugar that can be represented in terms of core language constructs, which is why I worry more about complex semantics.) > I want to say thanks for making this proposal (open namespace search > only for lexical references). It leaves most of the use-cases I > cited intact. Well done, good compromise (not complete evisceration > of property qualifiers, or dismissal of unqualified import). Thank you for saying so. I wonder what Mark thinks? (For the record, I think open namespaces as affecting lexical scope only would also remove the need for first-class Name objects.) > The helper/informative usage in the RI does open those namespaces, > and intrinsic works only as a cross-cutting namespace that can be > opened via pragma. So we should focus on these, if only to agree to > disagree on the importance of the former, argue for hardcoding the > latter via a separate early-binding pragma, and so forth. I'm not sure there is a good design for an early binding pragma is that is immune to the performance costs. One possibility I can think of is to it an error to access a property by an early-bound name on an object that lacks the early-bound version when the pragma is in effect (without explicitly qualifying it as not subject to early binding). That seems potentially icky. Regards, Maciej _______________________________________________ Es4-discuss mailing list Es4-discuss@mozilla.org https://mail.mozilla.org/listinfo/es4-discuss
