On Oct 11, 2010, at 5:25 PM, Nick Papoylias wrote:

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)

clearly a bug. Cna you open a ticket? if you could write a test it would be excellent. In fact this method was never build with multiple environment in mind :)

...

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

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project