Hi Göran,
On Wed, Jun 27, 2012 at 1:35 AM, Göran Krampe goran@krampe.se wrote:
- AFAICT this will (in contrary to my solution) remove the "modelessness"
we have today. Or in other words, a code snippet will behave differently depending on which environment you are in. One can argue that this also holds true today (class variables shadowing globals for example) but still. It reminds me of VA for Java where you had to tell the "Workspace" in which class it was being run (in order to get all the imports right). I am not sure I like where this is leading. NOTE: My proposal meant that all class refs were actually in full, never short. They just "rendered" short when it was reasonable.
Yes, you're quite right. It's the main difference between this proposal and VW, GST, and Gemán's GSOC work. I think Gemstone might be the only similar implementation, although I'm not conversant with the subtleties of Gemstone.
To me, this is a feature, not a bug. By giving up the notion of a single, universal view of the system, we gain a degree of freedom that we didn't have before. If we write code that doesn't rely on knowing where to find the classes it depends on, we gain the ability to redefine those dependencies without altering the code.
- Reading code will force me to always be aware of which environments are
imported into the package I am reading. Otherwise I will not know which class is referred to when I read "Manager". NOTE: My proposal would always expand names into full names if there were more than two in the image.
Also true. But you could say the same thing about dynamic dispatch: you always have to be aware the class of the receiver, otherwise you won't know what method will be executed. We mitigate message ambiguity with dev tools (implementors, explain) and we can do the same with class references.
- And finally, this is AFAICT the same "pessimistic" approach that Java
etc use - in other words, each developer/project will create his/her own little sandbox (=environment) and will start creating duplicate names for things (knowingly or unknowingly) and will never really "notice" this because this solution will never make it apparent that it has been done. NOTE: My proposal would lead to ambiguous names being rendered with full path and also asking the developer if he meant Color::Orange of Fruit::Orange whenever he tried to type just "Orange" - thus making him (and all others) aware of the slightly unfortunate name clash.
In practice we tend to do this already. We just pick a prefix and rely on that to avoid name conflicts. And why not? We're long past the point where we can have a single, unmangled namespace for all the classes that might get loaded into a given image.
Thanks for the pushback, Göran. Insightful as always.
Colin