[squeak-dev] Environments

Frank Shearar frank.shearar at gmail.com
Tue Jun 26 16:30:28 UTC 2012


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
> |
> |
> |
>


More information about the Squeak-dev mailing list