On Wed, Jul 4, 2012 at 4:41 AM, Frank Shearar <frank.shearar at gmail.com> wrote:

> One thing I didn't try when I looked at the above image was run the
> tests. They mostly fail because setUp uses "env := Environment new"
> instead of "env := Environment name: 'Some Name'" and so the lookup
> instvar isn't set. You probably already know this.

Well, I knew it was buggy… :-)

> I'd like to run an experiment with Environments, actually: on binding
> access, lazily create a subclass of the thing accessed. Initially,
> that would mean that in an Environment called 'Foo' when you say
> "Object new" the Environment makes a FooObject in the global space and
> exposes it as Object to the contained code. When you load a package
> that contains extensions to Object, they actually appear in FooObject,
> meaning that code outside the Environment doesn't see the extensions.
>
> This doesn't solve the problem of clashing extensions when you import
> two environments with a common extension, but it does mean that loaded
> code goes into a sandbox. The code being loaded could still "true
> become: false" but "Smalltalk at: #Object put: nil" would only affect
> the loaded code.

Interesting. I'm not sure if you'd actually have to create FooObject
globally. It could call ClassBuilder directly, and bind the resulting
class as Object. You might also have to create the alias
FooOriginalObject (or something) so that the browse could display a
sane class definition. (Otherwise you'd get 'Object subclass:
#Object…')

> Is there a place where we can get our hands on Monticello packages? Or
> does Environments require some bootstrapping?

Yeah, Environments requires bootstrapping, but I haven't figured out
how to do it yet. The image I posted is the one I did my hacking in,
and getting it to that state involved frequent saving and lots of
restarts. It's just a proof of concept.

That said, the MC packages are here: http://source.wiresong.ca/seed/

Colin