[squeak-dev] Environments

Frank Shearar frank.shearar at gmail.com
Wed Jun 27 14:59:38 UTC 2012


On 27 June 2012 15:54, Göran Krampe <goran at krampe.se> wrote:
> 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.

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
>


More information about the Squeak-dev mailing list