[Cuis-dev] Other potentially missing abstract methods

[Juan Vuletich]

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 Vuletich
www.cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20260407/b713da14/attachment.htm>