On Wed, Apr 9, 2014 at 10:50 AM, Chris Muller <asqueaker at gmail.com> wrote:


> If I'm developing a new app, I can already choose a different name to
> avoid conflict.  I want Environments to be useful when there are two
> _existing_ legacy apps that have _already_ chosen to use the same
> name.  Is that use-case handled by Environments?  My guess is, it is,
> as long as the names are changed only in the downstream (e.g.,
> calling) Environment, it is.
>
> For example, if WASession and MagmaSession had both been simply named
> "Session" from the very beginning but I want MySeasideMagmaApp to use
> them both, then I could import them each into their own Environment.
> Then I could import those two Environments into a third
> "MySeasideMagmaApp" Environment and prepend a prefix to one or both of
> them.  Since Magma is in its own environment, its own references to
> "Session" are correct.  And since Seaside is in its own environment,
> its own referrences to Session are correct too (Seaside Sessions).
> Finally, since MySeasideMagmaApp is in ITS own Environment, it can
> refer to MagmaSession and SeasideSession because I prepended "Magma"
> and "Seaside" prefixes.  Is this a correct understanding?
>

Yes. That's exactly right.


> Hm, seems like there'll need to be some way to set up Environments as
> part of the package-loading process, so they'll be loaded into the
> correct Environments...   Preamble script?
>

No a preamble because that would make the code know about environments,
which (as you pointed out) we don't want. For manual loading, we need to
make
it possible to open an MC browser for a specific environment, so you can
manage
the code it contains.

Load scripts should be able to set up environments programmatically and
load
packages into them. There isn't a nice API for that yet.



> PS -- I didn't mean to inundate you with questions.  I probably need
> to dig into it and actually try it out.  I was just trying to get a
> feel for the use-cases and usage conventions, so I knew where to
> start
>

No problem. The core environments code pretty good, but actually using them
is
still a hassle because the tools don't have support yet.

Right now I'm working on making Workspace environment-aware. Instead of a
pool
dictionary for local bindings, it'll have its own environment. Be default
it'll import
Smalltalk, but you can import other environments as well.  That's exposing
all sorts
of little issues that I'm working through.

Colin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20140409/96d809f1/attachment.htm