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@gmail.com | To: "The general-purpose Squeak developers list" squeak-dev@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@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@gmail.com | > | To: "The general-purpose Squeak developers list" | > | squeak-dev@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@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@wiresong.com | > | > | To: "Squeak-Dev developers list" | > | > | squeak-dev@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 | > | > | | > | > | | > | > | | > | > | > | | > | | > | |