[squeak-dev] References to a removed and reloaded class

Levente Uzonyi leves at elte.hu
Sat Sep 22 00:55:26 UTC 2012


On Fri, 21 Sep 2012, Eliot Miranda wrote:

> oops, missed your questions right at the end.
> 
> On Fri, Sep 21, 2012 at 1:13 PM, Levente Uzonyi <leves at elte.hu> wrote:
>       I guess we're going off the track with class renaming. The problem I'd like to solve is:
>       If we remove a class and then add a class to the system with the same name, then the methods which were referring to the class before the
>       removal are still referring to the same old class. This means that two bindings will coexist in the system with the same class name, but
>       pointing to different classes.
>
>       How is class renaming related to this?
>       One of the possible solutions is to move the removed class's binding to Undeclared. When you rename a class, then Class >> #rename: will check
>       if there's a binding with the new class name in Undeclared. The problem here is that Undeclared doesn't release bindings automatically (when
>       they are not referenced by any methods anymore), so bindings gone long ago are still lingering in Undeclared, therefore Class >> #rename: (and
>       also Trait
>                   #rename:) will #inform: the user about it, which breaks one of the
>
>       tests.
>
>       But there's another problem with this solution:
>       There's a test which tests if a removed class's method is still referencing to the class. So replacing the value of the binding with nil is
>       not possible.
>       If we don't replace the value with nil, then the binding isn't really undeclared. So there will be bindings in Undeclared with non-nil value,
>       which might have side effects in the system.
>
>       How does the solution I suggested work:
>       - when a class is removed, then its binding will be thrown away
>       - all methods referring to the class are recompiled. This means that if any such method exists, then a new binding will be created in
>       Undeclared and all methods will use that new binding.
>       The drawback is that mass class removal will be slower. Removing a single class will have no noticable difference for the user (20-40ms+the
>       recompilation time).
>
>       For completeness, here's a list of problems I don't want to solve now:
>       - Undeclared holding onto bindings forever
>       - Undeclared introducing Associations for classes instead of ReadOnlyVariableBindings
>       - how class renaming works
>
>       On Fri, 21 Sep 2012, Eliot Miranda wrote:
>
>             I don't understand.  How else can one use Undeclared?  Any binding in a method which is undefined should be in Undefined.  Hence
>             when a class is removed or when a class is renamed the binding should be moved to Undeclared and left
> 
> 
> Some code uses #at:put: only, others try #includesKey: and #at:ifAbsent: which might not work as expected (see above).
> 
> 
> OK, then fix the code.  at:put: seems right.  at:ifAbsentPut: will create the wring kinds of bindings right?

#at:put: is also wrong if the key is not in Undeclared yet, because it 
will create Associations. #includesKey: and #at:ifAbsent: will return 
false information if the binding is only referenced from Undeclared.

>  
> 
>
>             there, but when a class is renamed we can offer the user the opportunity to redefine methods that refer to the class with the old
>             name (edit the methods to change the name to the new name).
> 
> 
> Should a removed class's binding - which is still pointing to the class - be in Undeclared? Will it cause any issues that the binding is still
> pointing to the class?
> 
> 
> The removed class's binding must be in Undeclared, but its value must be nil.  If not, the class will not be reclaimed.  If there are instances of the
> class that's a different issue and the class will be marked as obsolete and only referred to by its instances (as was always the case).

Okay.


Levente

> 
>  
> 
> 
>
>       Levente
> 
>
>             One might think that on rename the binding can be reused and its key changed.  But this would leave the methods referring to the
>             new class but with their source naming the old name, hence on recompile the methods would now refer to
>             the binding ... in Undeclared.  So the only correct thing for me is to move the binding to Undeclared, and, if interactive, offer
>             up either a list browser of all references to the class, or an option to edit those methods
>             automatically.
> 
>
>                   The only reason I know about Class >> #rename: is because a test was failing when I moved the binding to Undeclared. It
>             might not be that hard to find the methods, but it's still extra work to be done. I'll check it out
>                   though, because class renaming is definitely more rare than class removal.
> 
>
>                   Levente
> 
> 
> 
> 
>
>             --
>             best,Eliot
> 
> 
> 
> 
> 
> 
> 
> 
> --
> best,Eliot
> 
> 
>


More information about the Squeak-dev mailing list