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