[Cuis-dev] Other potentially missing abstract methods

[Juan Vuletich]

I've just pushed some additional calls to #subclassResponsibility.

Thanks!

On 2026-04-07 4:13 PM, Facundo Javier Gelatti via Cuis-dev wrote:
> 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 Vuletich
>     www.cuis.st <http://www.cuis.st>
>     github.com/jvuletich <http://github.com/jvuletich>
>     researchgate.net/profile/Juan-Vuletich <http://researchgate.net/profile/Juan-Vuletich>
>     independent.academia.edu/JuanVuletich <http://independent.academia.edu/JuanVuletich>
>     patents.justia.com/inventor/juan-manuel-vuletich <http://patents.justia.com/inventor/juan-manuel-vuletich>
>
>
-- 
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/20260408/a058959d/attachment-0001.htm>