Colin,

Be aware that code written to run in namespaces will be much more difficult to port to platforms with different or no namespace implementations. A portable solution 9not to be confused with a portable implementation) would be preferable and without looking at details, I'd guess that you are going down the portable route, especially since you are not leaning on syntax...

Dale

----- Original Message -----
| From: "Colin Putney" <colin at wiresong.com>
| To: "Squeak-Dev developers list" <squeak-dev at lists.squeakfoundation.org>
| Sent: Monday, June 25, 2012 7:11:18 PM
| Subject: [squeak-dev] Environments
| 
| 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!
| 
| Colin
| 
| 
|