oops, missed your questions right at the end.<br><br><div class="gmail_quote">On Fri, Sep 21, 2012 at 1:13 PM, Levente Uzonyi <span dir="ltr"><<a href="mailto:leves@elte.hu" target="_blank">leves@elte.hu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I guess we're going off the track with class renaming. The problem I'd like to solve is:<br>
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.<br>
<br>
How is class renaming related to this?<br>
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 <br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
#rename:) will #inform: the user about it, which breaks one of the <br>
</blockquote></blockquote>
tests.<br>
<br>
But there's another problem with this solution:<br>
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.<br>
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.<br>
<br>
How does the solution I suggested work:<br>
- when a class is removed, then its binding will be thrown away<br>
- 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.<br>
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).<br>
<br>
For completeness, here's a list of problems I don't want to solve now:<br>
- Undeclared holding onto bindings forever<br>
- Undeclared introducing Associations for classes instead of ReadOnlyVariableBindings<br>
- how class renaming works<div class="im"><br>
<br>
On Fri, 21 Sep 2012, Eliot Miranda wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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<br>
</blockquote>
<br></div>
Some code uses #at:put: only, others try #includesKey: and #at:ifAbsent: which might not work as expected (see above).</blockquote><div><br></div><div>OK, then fix the code. at:put: seems right. at:ifAbsentPut: will create the wring kinds of bindings right?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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).<br>
</blockquote>
<br></div>
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?</blockquote><div><br></div><div>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).</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
Levente</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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<br>
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<br>
automatically.<br>
<br>
<br>
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<br>
though, because class renaming is definitely more rare than class removal.<br>
<br>
<br>
Levente<br>
<br>
<br>
<br>
<br>
<br>
--<br>
best,Eliot<br>
<br>
<br>
</blockquote>
</div></div><br><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div><br>