Well, yes to both.

Now, about the performance, first I'd like to have a benchmark suite that runs all the time, to at least understand if we lose some performance, when/why was it.
Of course, this would have an impact depending on how often are globals read/written. But I'd like to know with more certainty.

Also

[SystemNavigation new isUsedClass: IceRepository] bench��
��=> '172.497 per second'

So maybe we can pay the price of a couple of milliseconds every time we remove a class for the moment. I prefer a "bit slower" system that is more robust :)
Also, how often do we remove classes? I don't think this is critical, and the robustness here pays for itself :)
We can think about how to optimize it later.

Guille

On Wed, May 2, 2018 at 2:20 PM, tesonep@gmail.com <tesonep@gmail.com> wrote:
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-does-not-work-well-with-Undeclareds
>
> 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


Web: http://guillep.github.io

Phone: +33 06 52 70 66 13