<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Facundo,</p>
<p>This is very good!</p>
<p>After running these, I pushed seven change sets. Some do add the
#subclassResponsibility call. Others refactor the code a bit.</p>
<p>After these updates, your scripts still find many candidates. For
instance, in Case 2, it still finds Morph>>#rotation: . But
this one is ok, as the call on #rotation: is not to self! Same
happens for LookupKey>>#value:. LookupKeys don't even have a
value at all! In Case 3, not every dialog will include #cancel and
#ok, etc.</p>
<p>There are still other candidates where adding the abstract method
will make sense. A case by case review is needed.</p>
<p>Cheers,</p>
<div class="moz-cite-prefix">On 2026-04-03 1:05 PM, Facundo Javier
Gelatti via Cuis-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAC1UKnZA0uiXz00V9rnaM_sDk+gRM7Qy7+YGWq7+PLssiLxR6Q@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>Inspired by the email I sent about adding an abstract
method to SystemWindow, I built some scripts to try to
identify other abstract methods that are missing.</div>
<div><br>
</div>
<div>So, I attach three scripts that find classes and the
selectors of their potentially missing abstract methods. This
is the logic for each one of them:</div>
<div><br>
</div>
<div>Case 1: pretty sure we should create abstract methods for
these
<div style="margin-left:40px"> Analyzes classes we know are
abstract (i.e. which have abstract methods, have no
instances and have at least one subclass), selects the
methods that are implemented by <i>all</i> subclasses,
which <i>are not</i> in the abstract superclass, but that <i>are
sent</i> from the superclass to self.<br>
</div>
<br>
Case 2: also pretty sure, but in classes that don't have
abstract methods yet<br>
<div style="margin-left:40px"> Similar to Case 1, but the
classes that are analyzed don't have any abstract method.
Because the messages are sent to self from the superclass, I
strongly suspect that these should also be implemented as
abstract methods.<br>
</div>
<br>
Case 3: not sure, but worth checking<br>
<div style="margin-left:40px"> Analyzes classes we know are
abstract (similar to Case 1, but more constrained: the
classes should have at least *2* subclasses), selects the
methods that are implemented by <i>all</i> subclasses,
which are not in the abstract superclass, and that are <i>not</i>
sent from the superclass to self (to avoid repeating what
was found in Case 1).<br>
In this case we don't have the evidence of a message being
sent to self from the abstract class, but having all
subclasses (which are at least 2) implement the same message
from an abstract superclass is some form of evidence. For
example, I'm pretty sure we should have an abstract method
for Boolean>>#orNot:.</div>
</div>
<div><br>
</div>
<div>Being able to decide what to do with these findings
requires domain knowledge, so I'm not saying we should 100%
add all of these as abstract methods. Probably there are
better design decisions depending on the particular cases.</div>
<div><br>
</div>
<div>I hope you find this helpful!</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Facu</div>
<div><br>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
</blockquote>
<pre class="moz-signature" cols="72">--
Juan Vuletich
<a class="moz-txt-link-abbreviated" href="http://www.cuis.st">www.cuis.st</a>
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich</pre>
</body>
</html>