[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
|