[squeak-dev] Environments

Colin Putney colin at wiresong.com
Tue Jun 26 18:24:21 UTC 2012


On Tue, Jun 26, 2012 at 8:38 AM, Chris Muller <asqueaker at gmail.com> wrote:
> It sounds like a simple solution -- I do appreciate it's a pure OO
> solution rather introducing new syntax.
>
> However, things tend to "sound" simple when I barely understand them.
> Perhaps a concrete example would help me -- the basic use-case:
> pretend I have an application called "Application" that wants to use
> both Magma and Seaside in the same image and each wants to define a
> "Session" class.  They are developed by different developers.  In this
> context, could you clarify some questions?

Sure, that sounds like a great use-case for Environments.

>  - Somewhere, the Application would need to define the "order" of the
> Environments it depends on so it can sometimes use unqualified names,
> is this correct?  What would that code look like?

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:

  (Environment name: 'Seaside')
    importSmalltalk;
    fileIn: 'Seaside.st'.

  (Environment name: 'Magma')
    importSmalltalk;
    fileIn: 'Magma.st'.

  (Environment name: 'Application')
    importSmalltalk;
    import: #Seaside;
    import: #Magma;
    fileIn: 'Application.st'.

>  - What would the loading/initialization code look like that would
> put Magma's Session into its own environment?

You'd load all of Magma into the it's own environment, as above.

>  - What would the code to access Magma's Session (instead of
> Seasides) look like from within one of Magma's methods?

>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:

  Session new

>  - What would the code to access Magma's Session (instead of
> Seasides) look like from within one of Application's methods?

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:

  (Environment name: 'Application')
    importSmalltalk;
    import: #Seaside aliases: {#Session -> #SeasideSession};
    import: #Magma aliases: {#Session -> #MagmaSession};
    fileIn: 'Application.st'.

Note that I haven't implemented imports (except for Smalltalk) or aliasing
yet, so the protocol might end up being different.

>  - What would the code to access Magma's Session (instead of
> Seasides) look like from a workspace (Global environment?)

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.

Great questions Chris, thanks.

Colin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20120626/5ce4be68/attachment.htm


More information about the Squeak-dev mailing list