[squeak-dev] Environment changes in the Inbox

Jakob Reschke jakob.reschke at student.hpi.de
Fri Mar 3 14:23:34 UTC 2017


2017-03-03 0:06 GMT+01:00 Bert Freudenberg <bert at freudenbergs.de>:
>
> The general metaphor seems to be that an environment just replaces the
> global Smalltalk dictionary with its own, but the code in general doesn't
> even have to be aware of the existence of other environments. This is in
> contrast to how other systems handle modules and namespaces. Would you think
> this is a fair characterization?

The metaphor sounds adequate to me, but I think the validity of the
contrast depends on your view of what environments really are in the
context of modules or namespaces.

An object file compiled from C also does not know where its externals
will come from until it is linked with other objects or libraries.
Java classes also do not know where the other packages will come from
until a class loader starts collecting things from a classpath.
Environment variables (ha!) like PATH, CLASSPATH, PYTHONPATH, and
include paths might be a good analogy for our environments: they
provide a context to resolve names (executable names, fully qualified
class names, module names, included file names, and in Squeak "global"
variables) by the system (runtime, compiler/linker), and they
typically do not appear in the source code. They are part of a module
system, but they are neither the module system all by themselves nor
namespaces as a language feature. In fact, they are not language
features at all.

Our environments are different from those path variables in that they
support renaming and fine granular imports. In Python, Java, C++ this
is done by the language's "import" features. Hence, Python modules,
Java packages, and C++ namespaces (and C function prototypes, if you
want to look at them as imports) all do appear in the source code. For
this aspect, your contrast definitely holds.

It might be interesting that the centrality of PYTHONPATH also poses a
challenge to coexisting applications, leading to solutions like
virtualenv. In Squeak we can either use multiple images or use
multiple environments to resolve conflicts.


2017-03-03 4:23 GMT+01:00 Bert Freudenberg <bert at freudenbergs.de>:
> On Thu, Mar 2, 2017 at 6:34 PM, Jakob Reschke <jakob.reschke at student.hpi.de>
> wrote:
>
> Is it fair to say that we can pretty much ignore environments in daily use?
> That we only create one if we need it? Or do you think they would be useful
> for regular development?

You should not always need them and you can usually ignore them,
unless you run into Path classes frequently... ;-) If the Smalltalk
library ecosystem were larger (Java sized), the need for more explicit
namespaces or environments might be more pressing.


More information about the Squeak-dev mailing list