Hey!

On 06/27/2012 03:46 PM, Frank Shearar wrote:
> On 27 June 2012 09:35, Göran Krampe <goran at 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.
>>
>> 1. 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.
>>
>> 2. 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.

>> 3. 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.

> 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. ;)

regards, Göran