On 26 June 2012 03:11, Colin Putney <colin at wiresong.com> wrote:
> Hi all,
>
> There's an old joke in the Squeak community about how we have a flame
> war about namespaces every few years and only newbies bring up the
> topic casually. Well, it seems we're overdue, so I'd like to do my bit
> for the community by keeping up the tradition.
>
> I propose that Squeak 4.4, or perhaps 4.5, include support for more
> than one class with the same name. This will be a modest proposal,
> based on extending Dan's work on environments. The basic idea is this:
> an Environment is an object that implements a policy for binding names
> to objects during compilation.
>
> This is in direct contrast to the Namespace implementation that
> VisualWorks uses. In VW the global namespace is divided up into a
> dot-delimited hierarchy, and there are mechanisms for resolving
> unqualified names. Environments, in contrast, are more like Newspeak
> modules. There's no universal mapping of names to objects, but rather
> different "points of view," where names resolve differently depending
> on which environment you're in.
>
> The simplest and most common use for environments is to allow two
> classes with the same name to peacefully co-exist. We currently work
> around this problem with classname prefixes - MC in Monticello or WA
> in Seaside. With environments, we can do away with prefixes by
> creating a separate environment for each prefix that we're currently
> using.
>
> An interesting example of this case that I've run across lately is
> Xtreams. In the original VW version, there's only one class that's
> publicly visible: the Incomplete exception that gets raised when a
> stream operation fails. The rest of the public API to the library is
> provided as extensions to classes in the base system. There's actually
> no need for code that uses Xtreams to refer to any of the stream
> classes. That leaves a lot of room for the implementation of Xtreams
> to change while keeping the API stable, and I'd like to be able to
> take advantage of this design in Squeak. With Environments, that's
> possible: we just create an environment to hold the Xtreams classes,
> import the base system, compile Xtreams, export Incomplete, and import
> Xtreams into our application's environment.
>
> I've done a preliminary implementation, which lets me create an empty
> environment, file code into it and then browse and modify it with a
> standard browser. There's still lots of work to do, but I want to get
> a consensus among the core developers before tackling it. That way the
> changes can happen in the trunk and we don't have to worry about a
> difficult integration later.
>
> I've attached a couple of screenshots. The first shows two browsers,
> one browsing the base image, the other browsing an environment with
> Seaside 3.0 loaded. The second is an explorer on the Seaside
> environment. The image where they were taken is available for download
> here:
>
>    http://www.wiresong.ca/downloads/Environments.zip
>
>
> Flame away!

One thing I didn't try when I looked at the above image was run the
tests. They mostly fail because setUp uses "env := Environment new"
instead of "env := Environment name: 'Some Name'" and so the lookup
instvar isn't set. You probably already know this.

I'd like to run an experiment with Environments, actually: on binding
access, lazily create a subclass of the thing accessed. Initially,
that would mean that in an Environment called 'Foo' when you say
"Object new" the Environment makes a FooObject in the global space and
exposes it as Object to the contained code. When you load a package
that contains extensions to Object, they actually appear in FooObject,
meaning that code outside the Environment doesn't see the extensions.

This doesn't solve the problem of clashing extensions when you import
two environments with a common extension, but it does mean that loaded
code goes into a sandbox. The code being loaded could still "true
become: false" but "Smalltalk at: #Object put: nil" would only affect
the loaded code.

Is there a place where we can get our hands on Monticello packages? Or
does Environments require some bootstrapping?

frank