It sounds like a simple solution -- I do appreciate it's a pure OO solution rather introducing new syntax.
However, things tend to "sound" simple when I barely understand them. Perhaps a concrete example would help me -- the basic use-case: pretend I have an application called "Application" that wants to use both Magma and Seaside in the same image and each wants to define a "Session" class. They are developed by different developers. In this context, could you clarify some questions?
- Somewhere, the Application would need to define the "order" of the Environments it depends on so it can sometimes use unqualified names, is this correct? What would that code look like?
- What would the loading/initialization code look like that would put Magma's Session into its own environment?
- What would the code to access Magma's Session (instead of Seasides) look like from within one of Magma's methods?
- What would the code to access Magma's Session (instead of Seasides) look like from within one of Application's methods?
- What would the code to access Magma's Session (instead of Seasides) look like from a workspace (Global environment?)
It sounds like you're on to something to give Squeak a new a kung-fu move, thanks for pushing on this!
On Mon, Jun 25, 2012 at 9:11 PM, Colin Putney colin@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!
Colin