A little namespace "proposal"

goran.krampe at bluefish.se goran.krampe at bluefish.se
Tue Apr 6 17:05:59 UTC 2004


Hi all!

Rereading what Roel said I realized that I must have missed a whole
crucial piece of the puzzle in my presentation. I think.

goran.krampe at bluefish.se wrote:
> Hi Roel and all!
> 
> Roel Wuyts <Roel.Wuyts at ulb.ac.be> wrote:
> > 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. :)

It seems that I didn't explain this in my original post. Very strange, I
was *sure* I did. Anyway - this is the key piece of the puzzle and I
managed to miss it. :)

I repeat then:

I can only write "Delay" if there is just one such class in the image.
If another package is installed (or a class is created etc) and
introduces "Balloba::Delay" then all the methods in the image which uses
the short form "Delay" must suddenly "magically" use the qualified form
"Kernel::Delay".

I think I used the word "render" meaning that these class references has
always been to the class Delay in category Kernel-Processes - it is
after all "stored" as an object reference in the CM. But suddenly, when
it turns ambiguous, this reference is "rendered" as "Kernel::Delay" in
the source.


I also noted that this is wrong, I wrote:

"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."

No, the short form should only be usable when there in fact is only ONE
name in the image like that. This means you can only write "Delay" if
there is only one class called "Delay" in ALL the namespaces.

regards, Göran



More information about the Squeak-dev mailing list