<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 9, 2014 at 10:50 AM, Chris Muller <span dir="ltr"><<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>></span> wrote:<br>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If I'm developing a new app, I can already choose a different name to<br>
avoid conflict. I want Environments to be useful when there are two<br>
_existing_ legacy apps that have _already_ chosen to use the same<br>
name. Is that use-case handled by Environments? My guess is, it is,<br>
as long as the names are changed only in the downstream (e.g.,<br>
calling) Environment, it is.<br>
<br>
For example, if WASession and MagmaSession had both been simply named<br>
"Session" from the very beginning but I want MySeasideMagmaApp to use<br>
them both, then I could import them each into their own Environment.<br>
Then I could import those two Environments into a third<br>
"MySeasideMagmaApp" Environment and prepend a prefix to one or both of<br>
them. Since Magma is in its own environment, its own references to<br>
"Session" are correct. And since Seaside is in its own environment,<br>
its own referrences to Session are correct too (Seaside Sessions).<br>
Finally, since MySeasideMagmaApp is in ITS own Environment, it can<br>
refer to MagmaSession and SeasideSession because I prepended "Magma"<br>
and "Seaside" prefixes. Is this a correct understanding?<br></blockquote><div><br></div><div>Yes. That's exactly right. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hm, seems like there'll need to be some way to set up Environments as<br>
part of the package-loading process, so they'll be loaded into the<br>
correct Environments... Preamble script?<br></blockquote><div><br></div><div>No a preamble because that would make the code know about environments,</div><div>which (as you pointed out) we don't want. For manual loading, we need to make</div>
<div>it possible to open an MC browser for a specific environment, so you can manage</div><div>the code it contains.</div><div><br></div><div>Load scripts should be able to set up environments programmatically and load </div>
<div>packages into them. There isn't a nice API for that yet. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
PS -- I didn't mean to inundate you with questions. I probably need<br>
to dig into it and actually try it out. I was just trying to get a<br>
feel for the use-cases and usage conventions, so I knew where to<br>
start<br></blockquote><div><br></div><div>No problem. The core environments code pretty good, but actually using them is</div><div>still a hassle because the tools don't have support yet. </div><div><br></div><div>Right now I'm working on making Workspace environment-aware. Instead of a pool</div>
<div>dictionary for local bindings, it'll have its own environment. Be default it'll import</div><div>Smalltalk, but you can import other environments as well. That's exposing all sorts </div><div>of little issues that I'm working through. </div>
<div><br></div><div>Colin</div><div><br></div><div> </div></div></div></div>