On Thu, Sep 20, 2012 at 11:28 AM, Levente Uzonyi <leves at elte.hu> wrote:

> In order to fix this bug, I came up with two ideas:
> 1) Recompile all methods which point to the old class when the class is
> removed. This helps, because the class will be undeclared at that point, so
> a new binding will be stored in Undeclared and the same binding will be used
> when the class is added again. The drawback of this solution is that it only
> fixes references in methods and it's slow, since it has to scan all methods
> in the system.

Couldn't we just move the existing binding to Undeclared? That might
be unnecessary if there are no references, but I don't think it would
hurt.

> 2) Create a new object (a datastructure) which points to the binding weakly
> and provides fast lookup by class name. Store the binding in this object
> when the class is removed and when a class is added, then check this object
> for existing bindings (besides Undeclared). This solution is fast, but more
> complicated than the previous one. But the same kind of
> datastructure can be used to replace Undeclared, so it will not hold onto
> bindings unnecessarily and it won't have to be cleared manually.
>
> I uploaded a few days ago System-ul.497.mcz to the Inbox which provides
> solution #1. There are ways to improve the performance of SystemNavigation
>>>
>>> #allCallsOn: by ~20%, so it will take only 20-40ms more to remove a
>
> class from the system, which might be good enough for now.
>
> In 4.5 I'd like to implement solution #2 and replace Undeclared to work this
> way too, but I think for 4.4 we can live with solution #1. What do you
> think?

I'm not sure I follow solution #2, but we'll be addressing this stuff
anyway in 4.5 with Environments. We can certainly make sure this
doesn't crop up again.

Colin