Two points.1. Maybe we should centralize the removal of a class in a component as the class installer. So we can have it all in one place, and if we need to override and do fancy stuff.2. Yes to the messages to the environment, I am doing so to have multiple environments sharing the same methods. We can check how much does it affect the performance, because it opens a lot of different options to extend the language.Cheers,Pablo--On Wed, May 2, 2018 at 2:09 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
> On 26 Apr 2018, at 09:28, Guillermo Polito <guillermopolito@gmail.com> wrote:
>
> Hi,
>
> It looks you got bit by this issue:
>
> https://pharo.fogbugz.com/f/cases/21519/RemoveFromSystem-doe s-not-work-well-with-Undeclare ds
>
> It's not particular to Epicea. There should be a better management of Undeclareds in general in all Pharo.
>
It can be fixed by moving the binding to undeclared in #removeFromSystem:
This is done by adding
�� Undeclared declare: self name asSymbol from: Smalltalk globals.
before the "forgetClass: self logged:" line.
What we need to do in addition: Only do that when the class is referenced. #isUsedClass: does that, but it does integrate over all methods in the system.
(I sometimes wonder if we should not late-bind accesses to globals, that is, just compile them as message sends to the environment).
�� �� �� �� Marcus
Pablo Tesone.
tesonep@gmail.com
|
������ | Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - http://www.cnrs.fr Phone: +33 06 52 70 66 13 |