goran.krampe at bluefish.se wrote:
> > I would never want to see Delay, and always Kernel::Delay. In your 
...snip...
> 
> 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?
I think we can get almost the same benefit with less "voodoo-factor" if
we colorize the code differently and add a balloon help that
disambiguates it. I other words, make the changed display a feature of
the tools. This still leaves a question about the model. This implies
that lookup is fixed at compilation time. It also means that it is not
invariant over different orders of compiling the same packages of code.
Could be very, very annoying. IMO, what this means is that we cannot
trust implicit, default behavior when clashes do happen. When
developing, the programmer can be asked to specify things at compile
time. When distributing code that is supposed to interoperate with other
code, it isn't good enough, because the code doesn't ship with its
developer ;-)

To fix this, you need some kind of namespaces disambiguation
declarations, falling under "problem 2" that I mentioned in the "what
are they good for" post.

> 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. :)

I think almost everything lives in the default namespace, and that still
makes it unique enough (even without the "Kernel...." division). This
sounds like part of a way to keep it that way, which is a good start.

But I'm still not sure whether we all agree on what problems we're 
attacking.

Daniel