<br><br>On Tue, Jun 26, 2012 at 8:38 AM, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br>> It sounds like a simple solution -- I do appreciate it's a pure OO<br>> solution rather introducing new syntax.<br>
><br>> However, things tend to "sound" simple when I barely understand them.<br>> Perhaps a concrete example would help me -- the basic use-case:<br>> pretend I have an application called "Application" that wants to use<br>
> both Magma and Seaside in the same image and each wants to define a<br>> "Session" class. They are developed by different developers. In this<br>> context, could you clarify some questions?<br><br>Sure, that sounds like a great use-case for Environments.<br>
<br>> - Somewhere, the Application would need to define the "order" of the<br>> Environments it depends on so it can sometimes use unqualified names,<br>> is this correct? What would that code look like?<br>
<br>Yes, that does need to be defined, but that definition shouldn't be part of Application. Application should just refer to the classes it needs and leave it up the environment to know where they are. That means that environment management is done in your development tools, and when building images. To set up the environments for Application you might do something like this:<br>
<br><span class="Apple-style-span" style="font-family:'courier new',monospace"> (Environment name: 'Seaside')</span><font class="Apple-style-span" face="'courier new', monospace"><div><div> importSmalltalk;</div>
<div> fileIn: 'Seaside.st'.</div><div><br></div><div> (Environment name: 'Magma')</div><div> importSmalltalk;</div><div> fileIn: 'Magma.st'.</div><div><br></div><div> (Environment name: 'Application')</div>
<div> importSmalltalk;</div><div> import: #Seaside;</div><div> import: #Magma;</div><div> fileIn: 'Application.st'.</div></div><div><br></div></font>> - What would the loading/initialization code look like that would<br>
> put Magma's Session into its own environment?<br><br><div>You'd load all of Magma into the it's own environment, as above.</div><div><br>> - What would the code to access Magma's Session (instead of<br>
> Seasides) look like from within one of Magma's methods?<br><br></div><div>From a design perspective, we don't want Seaside or Magma to depend on each other. (Note that the Seaside and Magma environments don't import each other.) So within the Seaside and Magma environments, Session is unambiguous, and can just be referred to directly:</div>
<div><br></div><div><font class="Apple-style-span" face="'courier new', monospace"> Session new</font></div><div><br>> - What would the code to access Magma's Session (instead of<br>> Seasides) look like from within one of Application's methods?<br>
<br></div><div>Ok, this is the bit that's slightly tricky. Application needs to use both Seaside sessions and Magma sessions, so we need to disambiguate. Application code should just use arbitrary names, like WASession and MaSession, or SeasideSession and MagmaSession if that's more aesthetically pleasing. Then it's up to the environment to sort them out. We'd do something like this:</div>
<div><br></div><div><div style="font-family:'courier new',monospace"> (Environment name: 'Application')</div><div style="font-family:'courier new',monospace"> importSmalltalk;</div><div style="font-family:'courier new',monospace">
import: #Seaside aliases: {#Session -> #SeasideSession};</div><div style="font-family:'courier new',monospace"> import: #Magma aliases: {#Session -> #MagmaSession};</div><div style="font-family:'courier new',monospace">
fileIn: 'Application.st'.</div><div style="font-family:'courier new',monospace"><br></div><div><font class="Apple-style-span" face="arial, helvetica, sans-serif">Note that I haven't implemented imports (except for Smalltalk) or aliasing yet, so the protocol might end up being different.</font></div>
<div style="font-family:'courier new',monospace"><br></div></div><div>> - What would the code to access Magma's Session (instead of<br>> Seasides) look like from a workspace (Global environment?)<br><br>
</div><div>The workspace would have an environment as well, and there's be some UI for manipulating it. So Magma's session might be called Session or MagmaSession, or whatever is convenient for that workspace. We might even do some kind of automatic importing similar to the way undeclared variables work are handled.</div>
<div><br>Great questions Chris, thanks.</div><div><br></div><div>Colin</div>