On 26 June 2012 17:05, Chris Muller <asqueaker at gmail.com> wrote:
> This namespace solution is just for globals/class names correct?
> There could still potentially be method-name conflicts for extensions
> to classes in the Smalltalk environment, right?

Preventing method conflicts is a whole other kettle of fish.
Environments doesn't address this. (There are some interesting things
in the avoid-monkey-patch-clashing area, like "selector namespaces",
and classboxes, and probably some other things I don't know of.)

frank

> On Mon, Jun 25, 2012 at 9:11 PM, Colin Putney <colin at 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
>>
>>
>>
>