[squeak-dev] Environments question

Chris Muller asqueaker at gmail.com
Wed Apr 9 15:50:08 UTC 2014

> Indeed! Having code be unaware of Environments was one of the primary design
> goals. It should be the other way around: tailor the environment to the
> needs of the codebase. If you have an app that refers to the prefixed names
> already, just load it into an environment that doesn't strip them off. Or
> heck, keep loading it into the default environment, along with Magma and
> ignore environments completely.
> The only reason to change your code is because you want to use different
> (prettier?) names. In that case, do it on your own terms, with whatever
> naming conventions or development tools you want.
> The point of all this is to decouple the declarations of classes from their
> references, and as a result, remove the need for the community to coordinate
> the naming of classes. You, as the developer of Magma can use whatever names
> make sense in the context of developing Magma, and I, as the developer of
> MyApp, can use whatever names make sense in that context. Regardless what
> choices we make, it should be possible to set up an environment that lets
> MyApp use Magma without either of us having to change our code to make it
> work.
> Does that make sense?

It makes sense when stated at that (high) level.  I think what happens
for me is when I start to think about the details of daily
development, I start to get confused.  Let me see if I can talk my way
through self-understanding this.

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?

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?


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

More information about the Squeak-dev mailing list