[Cuis-dev] Other potentially missing abstract methods

[Facundo Javier Gelatti]

Hi Juan!

Awesome! Thanks for the changes and for your review !

PS: Also, you're right to point out that I missed to check that the message
should be sent to self in my scripts; I did know it was necessary, but for
some reason I forgot to actually put that in the code, my bad!

El mar, 7 abr 2026 a las 15:50, Juan Vuletich (<juan at jvuletich.org>)
escribió:

> Hi Facundo,
>
> This is very good!
>
> After running these, I pushed seven change sets. Some do add the
> #subclassResponsibility call. Others refactor the code a bit.
>
> 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.
>
> There are still other candidates where adding the abstract method will
> make sense. A case by case review is needed.
>
> Cheers,
> On 2026-04-03 1:05 PM, Facundo Javier Gelatti via Cuis-dev wrote:
>
> 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.
>
> 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:
>
> Case 1: pretty sure we should create abstract methods for these
> 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 *all* subclasses, which *are not* in the abstract
> superclass, but that *are sent* from the superclass to self.
>
> Case 2: also pretty sure, but in classes that don't have abstract methods
> yet
> 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.
>
> Case 3: not sure, but worth checking
> 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 *all* subclasses, which are not in the
> abstract superclass, and that are *not* sent from the superclass to self
> (to avoid repeating what was found in Case 1).
> 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:.
>
> 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.
>
> I hope you find this helpful!
>
> Cheers,
> Facu
>
>
> --
> Juan Vuletichwww.cuis.stgithub.com/jvuletichresearchgate.net/profile/Juan-Vuletichindependent.academia.edu/JuanVuletichpatents.justia.com/inventor/juan-manuel-vuletich
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20260407/86604547/attachment.htm>