There's a heuristic that says incremental wins are good, but there are cases that don't apply. ("The world is better off without Saddam Hussein in power, no?") How do we know that this isn't leading the kind of "half a loaf" (non-)solution that I tend to worry about?
Guy Steele once told me that the first thing he tries to get right about a language is the namespace. "Get that wrong and you'll never recover."
I like Andreas' way of comparing what the proposal does to the cost of programmer changes. Determining whether his analysis is correct depends, I think, on what the proposal is actually doing, no? I think it's possible to implement it in such a way that changes scale appropriately, but it is not yet clear to me that the code actually does things that way. -Howard
Hernan Tylim wrote:
+1
I like Goran solution. Its true that only fixes the "prefix" problem and not the "namespace" problem, as Andreas pointed out. But to me that is not a bad thing. its one step further to make Squeak a little more comfortable.
Regards, Hernán
On 29 Nov 2006 15:59:41 +0100, *Lex Spoon* <lex@cc.gatech.edu mailto:lex@cc.gatech.edu> wrote:
Andreas Raab <andreas.raab@gmx.de <mailto:andreas.raab@gmx.de>> writes: > Generally speaking, I'm -1 on the proposal, mostly because what the > proposal doesn't achieve is to make a real step towards enabling > scalability of development (which to me is really what we're > after). That's because the *author* of some code still needs to find > unique names (prefixes) that do not conflict with the rest of the > world and that a "change of prefix" becomes very, very expensive > because it's literally like renaming all of the classes at once (and > consequently breaking all of the code that uses any name from that > "prefix space"). It's a good observation. Nonetheless, a hierarchical global namespace seems a good step forward over a flat global namespace. I do not know about *this* system, but in general I would love if global variables and classes had long hierarchical names. Using the existing class categories would seem great for that. Right now, responsible programmers already fake a hierarchical namespace by putting prefixes in front of all their global names. At the very least, it would be nice to support this practice in the programming language. Ideally, you can even use long names ("Monticello") instead of short prefixes ("MC") and thus greatly reduce the chance of conflicts. In practice, I bet it's not so hard to pick prefixes that are unique in the contexts the package will be used in. Most of the time, you can just use the name of the project, which you have surely already gone to some efforts to try and make unique. If nothing else, all the open-source projects would benefit! Finally, keep in mind what the great naming systems you describe for the future would look like. They will probably still have path-based identifiers! The only difference from hierarchical names would likely be that the path can start from somewhere other than a single global root. Thus, a flexible hierarchical-naming system would seem like a good basis for the kind of naming system you are thinking about. (In particular, you would want Foo::Bar to really mean "Bar" within "Foo"....) -Lex
-- Saludos, Hernán