On 5 July 2012 00:28, Colin Putney <colin at wiresong.com> wrote:
> 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…')

Oh, definitely! Right _now_ ClassBuilder uses the SystemChangeNotifier
to announce the birth of a new class. If you do the naive thing (as I
describe above), even if you try add the new class to your own
SystemDictionary, you end up with a reference in Smalltalk globals.
That has... interesting effects. That's why I suggest a FooObject _for
now_ because while it spams Smalltalk globals, it does so in a
reasonably safe manner. Then we can make SystemChangeNotifier work per
environment, and THEN we can stop making FooObjects.

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

Mm, it's a proof of concept on which I want to hack :)

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

Thanks!

frank

> Colin
>