[Pharo-project] Hallo Pharoers.. namespaces in the system level ?

Stéphane Ducasse stephane.ducasse at inria.fr
Mon Oct 11 16:14:19 EDT 2010


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 at 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 at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project





More information about the Pharo-dev mailing list