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

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

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

Controlling classes is the easy part, but one thing at a time.

frank

> I am merely contrasting this with my own proposal from years back in order
> to hear people's views on the above aspects.
>
> Personally I am *happy* that this stone is finally turned.
>
> On the other hand I am *unhappy* that you aren't facing any opposition
> because unfortunately it may just indicate that our community have shrunk
> considerably and people are instead flaming each other over on Pharo-dev. ;)
>
> regards, Göran
>