Environments proposal by Colin Putney 2012
Last updated at 10:56 am UTC on 25 November 2015
Proposal by Colin Putney
Colin Putney
AttachmentTue, Jun 26, 2012 at 4:11 AM
To: Squeak-Dev developers list
Reply | Reply to all | Forward | Print | Delete | Show original
Hi all,
...
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
Colin
