On 27 June 2012 15:54, Göran Krampe goran@krampe.se wrote:
Hey!
On 06/27/2012 03:46 PM, Frank Shearar wrote:
On 27 June 2012 09:35, Göran Krampe goran@krampe.se wrote:
Hi Colin and all!
First of all - you are brave :)
Anyway, a few thoughts of mine, although I am no longer "invested" in this area, I was earlier but have given up waaaay back.
- 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.
- 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.
Which means tools might need adjusting. Hover over a class name and the browser tells you the local name and, if it's an import, where it came from and what its "real" name is.
(I'd love to have that kind of thing anyway, actually: in your Debugger, being able to hover over a variable to see its value would be marvelous. A topic for another day.)
Agree on both accounts. Just trying to remind us that this will add a "mental hurdle" in reading code. Sure, tools can help - but only so much.
- 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.
On the flip side it means I can safely compose two libraries that I'd really like to use together, but can't, because they use the same class names. And I can do that without rewriting source.
In fact, my solution (sorry for referring to it - but I do it for "comparison", not trying to push it) allowed that too because *all* class references in source code were always *in full*.
In other words - it worked just like prefixes does today. You can easily combine Seaside (WA*) with Monticello (MC*) and no names will clash. In essence, my solution was "prefixing improved", so it worked exactly the same.
It's not really implicit. Given two libraries with "Session", you'd import and _locally_ prefix as MaSession and WaSession. When you read the code, you'd see those names, note the prefix, and possibly check the Environment import list.
frank
More importantly, Environment is a wedge. First you can load multiple classes with the same name. Then you can hide classes, protecting a library's internals (Environment does this already). Then you can selectively import those external classes you need (Environment does this already). Then you can _only_ import external references, and not just rely on some ambient knows-everything environment. And hey, you're suddenly forced into declaring your library's dependencies. That is _good_.
Personally I just feel complexity lurking in the shadows... I hope I am wrong. ;)
It's more that complexity is right in the room and everyone covers their eyes, puts their fingers in their ears and goes "lalalala" at the top of their voices. Modularity is hard.
frank
regards, Göran