Hi!
If we then in a while decide my solution sucks... eh, I guess the only valid reason I can come up with would be that people think that 'Monticello::Dictionary' actually looks bad compared to 'MCDictionary', then sure, revert those 3 methods it is all about and remove the '::' so that it is now called 'MonticelloDictionary' - or hey, just replace 'Monticello::' with 'MC' and tada - we are back where we are now.
Renaming classes is not hard, we do it all the time. And if we ever want to move away from prefixes to anything else - whatever solution you think that we *ever* will be able to agree on ;) - then we would need to do the same anyway.
But this is my point. I think many people would use your solution because it *is* more natural to be able to just say Dictionary or SystemEditor or whatever within your package. So lets say that someone starts doing a lot of research on this in 2 or 3 years and come up with a solution 2 or 3 years after that. At that point I don't think renaming all the classes that will be using this will be trivial.
Let me just remind you that we *already* have that problem regardless if my solution gets in or not - in fact - we are even *worse* off. How come? Because we *already* use "prefixes" but unfortunately in a way that disables automated renaming. Just look: SMSqueakMap, WAComponent blablabla...
I think it will be a lot of work and thus not doable for the base image. I would just see it as a shame to not be able to adopt a new solution because of legacy.
See above.
What you said in your other message about it not coming up unless there is a conflict was good. That would make it easier to simply load other projects and not worry about conflicts, and then later fix them.
Yes, and let me here note that in my solution ALL references to globals are JUST LIKE TODAY. That means that they are ALWAYS fully qualified in the SOURCE. Sorry for the caps, but this is VERY important to realize.
It means that I can load 34 other packages into my image and as long as we don't have *namespace name* clashes (like two people using the same name for their namespace) nothing funky will happen in my source. All references are still perfectly correct.
The only diff is that when I *browse* the code that earlier said "Dictionary" now may say "Kernel::Dictionary" because my image now also contains "Joes::Dictionar" and "Schmoes::Dictionary".
But I just don't see it working like that. I think once namespaces are in they will be used whole-sale, and the reason I think that is what you said before: we are using them now manually.
Yes, again, see above - problem *already* exists.
I hope I don't sound too negative.
No problem, I just urge you to test it or read how it works. :)
I think you have done great work and it is good to be able to load namespaces if you need them at your company.
I don't think addon namespace solutions will ever be used. I wouldn't.
For a company, a quick stop gap is very needed because you have to deliver a product in a specific time frame. But squeak isn't under such constraints, so I don't personally see a rush to put something in the image for this.
Hehe, rush? Are you aware of when I wrote this? Are you aware of how many posts I have written about it? Are you aware of how awfully many times the question of Namespaces have come up on the list? It is one of the "deadly subjects" always causing an explosion of subjective views and always end in nada.
To be clear, I think your solution is great. I just disagree with making it default in the image.
p.s. Does it get the namespace from the category? If not, then that
might
be something to think about. :)
The class creation template borrows the category name in some fashion IIRC. But it is only a suggestion.
Well I don't know. It sounds like you avoid a lot of the ambiguity by simply forcing every class to be explicit if there is more then one with the same name.
Note that I thought you meant in what namespace a class is *created*.
My thinking with categories was: if there is a conflict then the package could automatically resolve to the category it is in, and all classes in that category resolve the conflict to mean the class in their same category.
This mechanism of "local" references is in my solution. So yes, if a method in Foo::Bar refers to Foo::Boo it will be enough typing "Boo" and it will render as "Boo" even though you have 100 other Boos in your image. But it will be "Foo::Boo" in the actual source - as always. Because that is the name of the class.
Note that these "policy" is nicely encapsulated in a single class - just check the code. We can play with different rules for this - but I agree - "local references" is a special case in which we can "guess" for the user. If he really wants "Blooper::Boo" then he will just have to type that.
The problem with that is that there has to be a way for those classes to explicitly reference classes in other packages, and anything not in that package must always explicitly reference which class they mean. There is also the problem that some implicit magic happens with conflict resolution. So this idea would also introduce new syntax (and thus I wouldn't go for it either).
Not sure what you mean.
regards, Göran