On Mon, Oct 11, 2010 at 5:11 PM, St�phane Ducasse
<stephane.ducasse@inria.fr> wrote:
>
> For example there currently exist a setter in the class side for 'migratting' in a new environment, that just alters the class knowledge about the new namespace and does not erase it's record from the old namespace.
where?
Class>>environment: (as far as I understand the class changes it's environment, without erasing itself from the old one and adding itself to the new one)
�
> Is this intented ? What is the underlying design ? Should we add an environment: setter in the subclass message, so that we integrate namespaces with the current Browser ? Should Behavior always return Smalltalk globals, or there should be a setter to be able to migrate a whole hierarchy of classes elsewhere ?
Normally a class should be able to return its environment and it can be different to Smalltalk globals, for example
we want to have to environments so that we can load Opal in one to modify the other Opal compiler that we will running.
Up to now marcus was using the old compiler to compile the new but in the future we only want one compiler and still been able to
change it.
Stef