Frank,

You were right to make that assumption, since the C-based compiler often does get in the way:)

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:47:12 AM
| Subject: Re: [squeak-dev] Environments
| 
| On 26 June 2012 17:44, Dale Henrichs <dhenrich at vmware.com> wrote:
| > 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.
| 
| Ah, excellent! I'd imagined (in my ignorance) that since GemStone has
| the (to my mind) unusual C-based compiler, that it might have issues
| in this regard.
| 
| frank
| 
| > 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
| > | > |
| > | > |
| > | > |
| > | >
| > |
| > |
| >
| 
|