Hi!
On Nov 30, 2006, at 12:45 AM, Göran Krampe wrote:
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".
There's one thing I'm not clear on from the writeups is how legacy and namespaced code are meant to interact in this proposal, in the phase were it is being introduced. Apologies if this has been covered, its been a long thread.
You have no idea how long. :)
Sample scenario
I take a clean 3.9-ish image. I load the namespace support. I load a package that introduces the classes Someones::SharedQueue and Someones::Something <would that work, given that there is a naked SharedQueue in the system?>
Yes. You now have two classes, one named #Someones::SharedQueue and one named #SharedQueue. Just like with prefixes today.
I go into a method in Someones::Something and type SharedQueue new.
Does this prompt a disambiguation question, and if so, how do I indicate that I want to use the system's
SharedQueue?
This is a good example. If you had written SharedQueue in Foo:: then when saving a popup menu comes up and asks which one you want. You select which one and Squeak will correct the code by inserting the prefix, if you selected Someones::SharedQueue.
But if you type it in Someones::Something then there is a policy that says that "local" references (=typing a short name that has a match in the namespace of the class that you are editing, regardless of other matches in other namespaces) are assumed to mean the local one - so it will not ask and it will not expand visually to Someones::SharedQueue - BUT the source will read "Someones::SharedQueue". Theoretically we could meet half way - not asking, but still expanding it visually - but that is not how it works today.
I can't verify this right now - but I am pretty sure this is how it works and how I meant it to work - local references is such an obvious special case that I think it is worth "deviating" from the rule that a short name always means that there are no other such short names in any of the other Namespaces in the image.
But note that this "lookup policy" for local references is actually a "Tools Issue" - we could even make that a Preference! Or you could hack in "imports" and use that. And I have isolated this policy in the code in a single class to make it easy to experiment with.
The answer earlier about how yes, one could use existing categories as defaults, but you'd do it in the class-creation template, prompted this question. What is the default full name of an existing class, when your changes are first incorporated into an image?
It depends on how we wish to partition the classes we already have, see below.
I.e. where did 'Kernel' come from in your example above, if not by automatically namespacing legacy code by category? And if that is done, does it immediately affect the content of all fileouts and package commits?
We have three choices:
1. Keep the basic classes unprefixed just as now. 2. Introduce a single space for all basic classes, like Kernel::. 3. Cut the basic classes up in several namespaces.
IMHO #3 is bad. We aren't talking about Modules nor Categories. The base classes are maintained by the same group of humans (=us) and we can make sure all their names are unique - so we should just have ONE space.
#2 was what I first envisioned - but now that you posted I recollect that someone thought it was better to just keep them in the "unprefixed Namespace" which equals Smalltalk.
So disregard my previous post and forget about Kernel:: - I recommend #1.
Or is it the case that you can't introduce a namespace-prefixed name whose base name is also present as a naked legacy class name?
If we go for #1 - that is correct since all Namespace instances are also globals. In other words - at the same instant you create Foo::Bar, the system will instantiate the class Namespace and put that in Smalltalk at: #Foo.
Sorry for the confusion.
regards, Göran