Frank,

As far as GemStone is concerned we've had separate environments for classes for a very long time. Instead of a Smalltalk dictionary, GemStone does global lookups using a list of dictionaries (SymbolList) and this list can be dynamically adjusted by the user. So in the end, I'd think that it would be straightforward to add this type of namespace to GemStone. 

We've also got dynamic lookups for methods as well ... it's what we've used make it possible to run Ruby in a Smalltalk environment and it's what we use in GLASS for the Squeak/Pharo compatibility later ... I haven't looked at what it would take to isolate the method look up to an environment (i.e., environment-specific extension methods to shared classes), but it's something that we'd eventually like to do.

Dale

----- Original Message -----
| From: "Frank Shearar" <frank.shearar at gmail.com>
| To: "The general-purpose Squeak developers list" <squeak-dev at lists.squeakfoundation.org>
| Sent: Tuesday, June 26, 2012 9:30:28 AM
| Subject: Re: [squeak-dev] Environments
| 
| On 26 June 2012 17:26, Dale Henrichs <dhenrich at vmware.com> wrote:
| > 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...
| 
| One non-portable part would be the ClassBuilder extensions! That lets
| you plug a new class into an Environment. I'm not sure how you'd coax
| an external compiler (Gemstone) into installing a new class into your
| new, isolated, environment.
| 
| frank
| 
| > 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
| > |
| > |
| > |
| >
| 
|