Hello Colin,

good to see you moving on with the design and implementation of Environments.

The scenario you outline with code makes sense to me.

What does
     importSelf;
     exportSelf;

do?

More comments will follow.

Regards
--Hannes


On 3/2/13, Colin Putney <colin at wiresong.com> wrote:
> Hi all,
>
> So I've been plugging away at Environments, and have a new implementation
> that supports renaming, but I wanted to get some feedback before figuring
> out the sequence of commits necessary to update the trunk safely.
>
> The idea is to support this kind of scenario:
>
> seaside := (Environment named: #Seaside)
>   import: Smalltalk globals;
>   importSelf;
>   exportSelf;
>   yourself.
>
> magma := (Environment named: #Magma)
>   import: Smalltalk globals;
>   importSelf;
>   exportSelf;
>   yourself.
>
> app := (Environment named: #AwesomeApp)
>   import: Smalltalk globals;
>   import: seaside;
>   from: seaside import: {#Session -> #SeasideSession};
>   import: magma;
>   from: magma import: {#Session -> #MagmaSession};
>   importSelf;
>   exportSelf;
>   yourself.
>
>
> In order to have the decompiled code use the correct names, I've changed
> the way lookup works. Instead of moving bindings from one environment to
> another, we now create a separate set of bindings for each environment, and
> copy the values (i.e., classes and globals) into a new binding when a
> binding is imported.
>
> I had originally thought to use something like #changed:/#update: to keep
> all the bindings in sync, but then I realized that ClassBuilder does a
> #becomeForward: updates a class. So it's really only globals that could
> become out of sync between environments. Since we have very few globals in
> the image, and they basically never change, an update mechanism may not be
> necessary in practice.
>
> So, here are some possible ways to proceed:
>
> 1. Use #changed:/#update: or something similar to keep keep global
> variables in sync.
>
> 2. Idea from Eliot—adopt the same convention as VW, and send #value to the
> binding on every access. Then we could have a special Alias bindings that
> forward the #value message to the original binding.
>
> 3. Share bindings for global variables between environments and disallow
> renaming of globals.
>
> 4. Special case the traditional globals such as Transcript and Display, and
> disallow the creation of new globals.
>
>
> Anyhow, I'd appreciate a code review from anybody who's interested in this
> stuff. To take a look, file the attached (hand edited) change set into an
> updated trunk image.
>
> Thanks,
>
> Colin
>