Hi!
Markus Gaelli gaelli@emergent.de wrote:
On Nov 29, 2006, at 9:42 AM, stephane ducasse wrote:
PS: I have been working with VW recently and I really found namespaces getting in my way all the time. Also the integration of namespaces in VW is badly supported at the refactoring level and other tools. So this is often a pain.
I agree with Andreas and Stef. Working with Seaside in VW right now, I can find 3 (three!) "versions" of Date in VW (Core.Date, Squeak.Date and Seaside.Date)! It kind of sucks to have to extend Seaside.Date with date method extensions already existing for Core.Date for this local shop.
Maybe namespaces of VW helped to get seaside ported to VW at all, but I'd prefer to have an ongoing desire to unify classes, which _are_ intended to work the same.
It might be worth mentioning how this would work with my solution.
The idea I have talked about earlier is that "my" solution is "optimistic" in the sense that there are no imports (which can be called a "pessimistic" approach). So if you have those three Date classes in the same image and just type "Date" then Squeak asks you which one you mean and offer a menu with all three to pick from. And when you pick it, kit gets expanded to say "Code::Date" in the browser.
In the source it is always "expanded" - it is just that the code is "rendered" with short names if Squeak knows that they are unique in the image anyway.
This means that having several "clashing" short names in the image will make it apparent that they are indeed clashing - because it will "annoy" developers that they can't just type Date and be done with it. So this is a poisitive thing - it acts like a "force" to unify classes with the same name - or rename one of them.
If you use imports then each developer sits in his/her little own box and don't "notice" that they have clashing names. And thus we more easily end up with tons of Date classes. :)
regards, Göran