hi colin

>> As far as namespaces go, the problem to be solved seems much easier,
>> and I think everybody agrees that a heavy-weight solution like in VW
>> is inappropriate. I profoundly disliked in VW the fact that they
>> namespaced the base image in a lot of small, meaningless namespaces
>> (although there was no name conflict to be solved), just as a display
>> of what could be done with them. I disliked the fact that namespaces
>> were made into as first-class objects as classes, to my mind without
>> the same conceptual justification. I also profoundly disliked that
>> they now had both namespaces (for the rest of us) and namescopes (for
>> the compiler) as two very similar (and with very similar
>> responsibilities) class hierachies, but yet distinct.
>> I think that the name lookup rules for the compiler should be the same
>> as the ones for our code, and I think that the base image should
>> contain no namespace other than Smalltalk. There is indeed potential
>> for name conflicts when independently developed packages are put
>> together in the same image. But if we are only trying to solve this
>> issue, and we don't mix it with categorizations (which should be done
>> by packges), I would think that a simple rule like "all external
>> applications' classes and packages should live in their own (only one)
>> external namespace" should be sufficient. This could easily happen
>> automatically, with a prompt for an image-wide development namespace
>> at the first class creation (like the initials prompt for the
>> changeset). Each corporation would have their own namespace and they
>> would do all of their development in it. And a few priviledged among
>> us like Dan (and maintainers of what is accepted as part of the base)
>> would always just type "Smalltalk", and that would be it :)
>
> Agreed. I've already mentioned that I'd like to see a decoupling 
> between the structure of the program elements in the image and the 
> compiler's binding of names to objects. The Forth strategy sounds 
> right to me.

I'm not that sure in fact.
If you look in VW the worse to me is class level namespace import.

But now after the experience with classboxes (basically a classbox is a 
changeset that lives inside
a namespace and whose extensions are scoped: ie only visible for the 
guy inside the classbox)
I'm not sure that namespace are worth.
Finally what I like with classbox namespace part (not the fact that 
class extension are scoped (which I like but is another point), is that 
for a developer when I'm coding my method I do not think that there are 
namespaces around.
When a name is not found, the borwser pop up and asks me, I found two 
Array classes in the system, then I pick
one and there is an import statement added in the namespace and this is 
it. After I can see array as normal.
The first paper on classbox is 
http://www.iam.unibe.ch/~scg/Archive/Papers/Berg03aClassboxes.pdf
But again I'm not sure that we need them.

Because how forth is different that having classpath problem after?
Stef