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. So you can't add one pragma and realize speedups or better type signatures for built-in methods. All you can do is access global intrinsic::foo bindings, which (in ES4, where opt-in versioning gets you immutable Object, Array, String, etc. without needing to open intrinsic) are few and not likely to realize a speed-up or more precise typing. So early binding via namespacing would be gone. It could be reintroduced via an ad-hoc pragma. But that takes up complexity budget in the spec and real implementations too. > It could save a lot of complexity, by not requiring any first-class > support for namespace lookup on arbitrary objects. If I understand your proposal, meta::get or iterator::get could still be defined in an arbitrary object, and called with full qualification. >> Lexical context, no dynamic open-namespaces scope. > > Note I said "compile to" so I think this was clear. Just dotting an i, especially for everyone following along at home :-). >> * internal namespace per compilation unit for information hiding >> -- hardcode as a special case? > > I'm not sure how this applies to unqualified import of namespaces > on arbitrary object properties. Per the spec, internal is open in a separate set on the list of open namespaces. You don't have to qualify references to internal::foo. >> * iterator and meta hooks in objects. Ugly __get__, etc., names >> instead? > > Unqualified import is not necessary for iterator or meta hooks. > Namespaces by convention (or __decoratedNames__) would be enough. Agreed :-). >> * helper_foo() and informative_bar() in the RI? > > I don't think any language feature should exist solely for the > convenience of the RI. It's not just the RI. Namespacing for informative purposes in the RI is good programming style, akin to using helper namespaces in C++ where top-level (but often class-level as you can see from reading RI builtins/*.es). `grep 'use namespace ' builtins/*.es` runs to 41 lines. > If more effort must be spent the necessary complexity of the > language just to preserve current levels of performance, No, to increase the levels of performance for the current version of the language. That's the horse going over the first hill from the barn. Adding namespaces to the next major version could slip into the optimization frameworks under way in a couple of engines I know of. But you may doubt. That's ok. I maintain that the high order bit should not be the cost to implementors, rather utility vs. complexity facing users. > then that takes away resources from implementing unnecessary > complexity to improve performance beyond current levels. Or harmonizes with the "unnecessary" complexity that implementors trying to compete already face. Let's not prejudge the ability of competing implementations to (a) speed up; (b) optimize namespace search for common code. The first target has to be the programmer using the language, not the implementor. This does not mean implementor concerns do not matter, as I keep trying to reassure you -- only that they come second. > In general, keeping the language simpler is good for performance. Yet focusing on performance can complicate the language for programmers. It certainly has for other languages. > Other things being equal, simpler implementations are easier to > change, and have more room to add complexity for optimization > without becoming too complex for human understanding. > > I will agree that some added language features are essential but I > think minor improvements in expressiveness that have large > complexity cost are a poor tradeoff. Hard to disagree without more details. This is motherhood and apple pie stuff. >> This is a good trade-off if it can be done in reasonable >> footprint, since there is a huge installed base, and a pretty-big >> knowledge base. We're not, for example, going to remove the >> ability to replace String.prototype.charAt, in any compatible ESn >> version. > > Preserving compatibility with existing performance-harming features > is not the same thing as introducing new ones. Since I did not say it was, I'm not sure why you are writing this. Obviously the bone of contention is benefit to programmers vs. cost to implementors. You allow as how the language must grow, which is a challenge to implementors, if not to programmers (who should see reduced need for boilerplate and library solutions). So we should get back to details. > Programmers have found ways to live with today's performance, and > it is true that for some applications core language performance is > not the bottleneck. But that doesn't mean we can feel free to > ignore performance considerations in the design of new language > features. Yeah, yeah. I do not mean to blow off this point. We've discussed performance and footprint throughout the last two+ years. No one feels free to ignore performance considerations, and what I wrote did not ignore those considerations. >>> I suspect the answer to this in AS3 is that if you want >>> performance, you have to use type declarations. >> >> That may be the case for AS3 code using Flex, but even such a >> result would be informative -- don't open multiple namespaces if >> you're using untyped objects and targeting an unoptimized >> implementation. >> >> But really, why is any of the several feature combinations that >> could hurt performance (with, eval, deep scope chains and >> prototype chains in most implementations) a reason to cripple the >> language? Performance is not king, and JS ain't C++. > > Is removing unqualified import of namespaces at non-global scope > (the only aspect of namespaces that seems prima facie harmful to > performance) really "crippling the language"? Depends on how much you value 'use namespace intrinsic' in particular, and the ability open "expert" or "version2" namespaces that cut across programs, classes, and objects in ES4 applied to large-scale programming in general. 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). 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. /be _______________________________________________ Es4-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es4-discuss
