On 9/19/07, Göran Krampe <goran at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20070920/b246b49d/attachment.htm