Hi Roel and all!

Roel Wuyts <Roel.Wuyts at ulb.ac.be> wrote:
> Hi Goran,
> 
> Just wanting to make sure I got what you were trying to do, so I could 
> give constructive comments instead of wandering of into some unintended 
> direction :-)

Hehe. :)

> So, executive summary of the problem: to have less chance of having 
> name conflicts between classes in different packages (your point 1). 
> The other points seem to be more future-directed (I mean, not adressing 
> a direct goal, but interesting things we could add later).
> 
> I agree to the goals you set out (except for the "optimistic", since I 
> don't think I get the real point, but ok). Indeed, if you want to add a 
> backwards copatible, non-obtrusive, easy-to-use mechanism then these 
> are the goals you want.
> 
> Now about the model itself (hehe, I bet that you are sitting on the 
> edge of your seat, Goran :-) ): I like it. I think it tackles your 
> problem. I put some comments in your original proposal below.
[SNIP]

> > - There is no explicit "creation step" for a namespace (or removal) -
> > they are simply created and removed "on demand" or whatever. This means
> > we all can "carry on just like before". :) Or in other words, it is an
> > attribute of the class.
> 
> Yes, I think I like it. But it is very dubious: it means that it is 
> easy to make stupid spelling mistakes when creating the class, 
> resulting in a namespace being created without me knowing it (see 
> further).

We could add a little "confirm". :)

> > - When writing code you can refer to the class Delay in two ways -
> > "Delay" or "Kernel::Delay":
> >
> > 1. If you type in "Delay" then we first look in the local Namespace of
> > the class you are editing. If there is a "Delay" in that namespace then
> > we bind to that. If not, then we look in ALL other Namespaces and if it
> > resolves in none we signal an Exception. If it resolves to one we ask
> > the user to confirm the right binding. The source will still read
> > "Delay" but the binding is still in itself fully qualified as
> > "Kernel::Delay" since it is in fact an object reference to that class.
> > If it resolves to more than one, the user gets to choose which one and
> > it will be expanded to "Kernel::Delay" in the source (if that is the 
> > one
> > he/she chooses).
> 
> I would never want to see Delay, and always Kernel::Delay. In your 
> proposal, things get ambiguous if one adds another namespace that 
> introduces Delay later on. To make sure I am clear, I'll give a little 
> scenario:
> (1) I add a class Roel::Classification, so a namespace Roel exists, and 
> my class in it.
> (2) I add a class Roel::Item, that has a method foo that somewhere 
> says: 'Classification new'.
> 	We all know what this means: a Roel::Classification new. So in your 
> proposal, the source reads as above, in mine it would read 
> 'Roel::Classification new'.
> 	No problems yet.
> (3) I load another package that has a class Alex::Classification (or I 
> add it myself, doesn't matter).
> (4) I open a browser on my class Roel::Item, and have a look at the 
> source code. Now it is not so clear anymore which classification is 
> meant without the prefix.

That is why I tried to explain that as soon as Alex::Classification
enters the image your code in Roel::Item>>foo will suddenly read like
"Roel::Classification new". Hmmm, didn't I write that? Perhaps not. That
was at least the intention!

The idea is to allow the short form if there is no ambiguity in the
image. And expand it to the qualified form if there suddenly is. So this
means that source will "change" under our feet. :) But hey - this is
Squeak and we can do that, can't we?

It is that trick that makes it so beautiful IMHO. Because it annihilates
the use of imports - since most available classes will be uniquely named
in themselves. :)

> So I am afraid that omitting the namespace is not a good thing with 
> respect to evolution and change. Adding the prefix makes it sound 
> again. And because needs to do the same checks, it does not even change 
> anything for the developer.

I am not sure you understood that the class reference is always
qualified "under the hood" but we choose to "render it" like "Delay" (if
there is no ambiguity) and automatically turn it into "Kernel::Delay" if
there suddenly is disambiguity.

> Note that this also means that it is more likely to notice spelling 
> mistakes with namespaces, since you've much more chance to see them. 
> When the lookup finds them in the misnamed namespace, you probably 
> won't see a mistake until much later, which can be quite annoying.

The problem here is that having all class references in the source being
fully qualified will get messy to read. And then people will start
yelling for imports and hey, there we go down the Java path...

> > Note to Andreas: The signals and code here is of course up for
> > discussion, I really don't care as long as the end result is the same.
> > :)
> >
> > 2. If you type in an explicit reference "Kernel::Delay" then the
> > Compiler (or whatever) first checks for the Namespace "Kernel" and if
> > that exists looks for the name "Delay" in it. If it isn't resolved then
> > an Exception is signaled and the Browser should look through all other
> > Namespaces for "Delay" and if found - ask if it should be corrected. If
> > there is only one Delay in the system to find, then it can be corrected
> > to "Delay", otherwise it will be corrected to the fully qualified form.
> >
> > The net effect of the above is that Squeak code as it stands today 
> > still
> > works fine after a recompile. I think. :).
> 
> Yes, I also think. Even in "my version".
> 
> > Note also how this eliminates
> > the needs for imports, the short form is usable in two scenarios:
> > 	1. The name referenced is in the local namespace.
> > 	2. There is only one such name in all the other Namespaces.
> >
> > This will also encourage us to to still have globally unique names in
> > our packages which is a GOOD thing because no matter how cool 
> > namespaces
> > we have - it all ends up in our heads - and our heads is just one big
> > namespace. If many namespaces have "Delay" entries, it will still mess
> > with our heads. See below for a little "feature" that still makes it
> > possible to have duplicate names without "disturbing others".
> >
> >
> > - When a new class "SqueakMap::Delay" is created the tools should warn
> > me that there already is a class called that in another Namespace and
> > that it is generally better if the classes don't conflict by name
> > because of the way resolving works. Sure, currently (before we get a
> > superserver somewhere that can do lookups globally) this only checks
> > against my current image but should still be useful.
> >
> > I then have a choice:
> > 	1. Keep the name Delay and thus causing people with my code and the
> > Kernel code in their image to be forced to choose which Delay they mean
> > every time they only write "Delay" instead of a fully qualified name.
> > 	2. Rename it to MapUpdateDelay and be fine, that might very well be a
> > more precise name.
> > 	3. Keep the name Delay but mark the name in the namespace as "shy". 
> > All
> > names in all namespaces are by default used when trying to resolve a
> > non-qualified name (as the resolving algorithm above showed - this is 
> > at
> > the heart of the "optimism") and marking it as "shy" merely means that
> > when someone writes "Delay" the entry "SqueakMap::Delay" will not be
> > presented as a choice. It doesn't mean anything else - for example,
> > typing "SqueakMap::Delay" works just fine regardless if it is "shy" or
> > not.
> 
> No, I don't like the last option at all. 1 and 2 leave the 
> responsibility in hands of the developer, which I like for handling 
> this kind of conflict. Option 3 is more complicated, you'll have 
> kind-of invisible stuff going on, you need to declare the shy-ness when 
> you add the class (since you don't create namespaces explicitly), etc.

Yeah. Tell you what - we can skip it to start with and then if we never
feel the need for it then you were right. :)

regards, Göran