On 9/19/07, Göran Krampe <goran@krampe.se> wrote:

At this point people may be confused but it all boils down to this usage
pattern:

        - If you want to have a class Apple in your own namespace "Fruit", just
name it "Fruit::Apple"! It is that simple.
        - If you want to move it, just rename it! The Namespace instances I
describe are automatically created and maintained.
        - If you want to use it, just type "Fruit::Apple" (because hey, that is
the name of the class!) but of course, you don't want to type all that so
fine, just type "Apple" and it will automatically work! Different things
will happen then:
                - If there is no other Apple in your image it will just work. Apple. No
prefix needed. This covers 98% I guess.
                - If there are multiple Apple, Squeak will ask you which one you mean
(nice popup menu) and autoexpand it in place!
                - If there are multiple Apple BUT one of them is in your LOCAL namespace
(=the namespace of the class you are editing) then it will work just
fine with the short form, the local Apple is chosen instead of the
others. This covers perhaps 70% of those last 2%. :)

This is more or less how you'd interact with my tools too, except that half the steps won't work yet :-).

My thoughts on your proposal, which I'm trying to keep technical rather than judgemental:

* It's a one-way street to adopt your proposal. I assume that file-outs and changesets will have all names contain "::". This means that any non-namespaced image can't use these file-outs, changesets etc.

* I assume that operations you perform on your namespaces such as renaming them will involve the tools modifying the source code for every method that uses that namespace? This isn't exactly elegant.

* I also assume that to resolve conflicts of the namespace names themselves, the tools need to give the namespace a completely new name (which changes the source code as it's filed in), and to do this you'd need input from the user?

* If non-namespaced code is loaded into the image, the user will need to manually resolve all ambiguous names, of which there will be more of because developers don't need to use class name prefixes any more.

* Your proposal still involves the use of a global dictionary containing all global variables and classes. In computer science we learn that the use of global variables should be minimised, and your proposal certainly doesn't help us in this regard.

* Your proposal doesn't completely solve naming collisions but instead reduce the likelihood of a collision happening. Collisions can still happen, and we still need to collaborate among ourselves to make sure two people don't use the same namespace.

In effect, what you're presenting as a namespaces implementation for Squeak is a way to hide class name prefixes from the developer, with a well-defined prefix format. It doesn't provide code with a particular context to resolve names in, but rather asks the user on a name-by-name basis to resolve ambiguity.

I'm not against your proposal, and it doesn't make the situation any worse than the current situation except for the filing out issue.

So +0 from me :-). I'd just like to ask you to put an easily-findable comment in the core parts of Squeak you change so that it is possible to remove it.

Gulik.