On 5 July 2012 10:30, Levente Uzonyi <leves at elte.hu> wrote:
> On Wed, 4 Jul 2012, Frank Shearar wrote:
>
> snip
>
>
>> 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 wouldn't work, because if you add an extension method to Object, then
> you have to create a copy of all classes of the global environment which are
> accessed from your environment (plus their superclasses up to Object).

In which you just lazily create those, even though my naive idea's now
a lot more expensive. You almost might as well just spawn a new image.

> But
> in practice this doesn't work, because the VM has some expectations about
> some objects/classes (true, false, nil, LargePositiveInteger, etc).

Right. So what you're saying is that if you want proper modules, you
need VM support.

> Also
> you'd have to convert objects which are passed from one environment to
> another, otherwise code like
>
>         foo class == bar class
>
> would break.

How would you pass objects between environments? What does it mean to
pass objects between environments?

frank

> Levente
>
>
>>
>> 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.
>>
>> Is there a place where we can get our hands on Monticello packages? Or
>> does Environments require some bootstrapping?
>>
>> frank
>>
>>
>