[Cuis-dev] Other potentially missing abstract methods

[Facundo Javier Gelatti]

Interesting! I'm not sure if I understand, though. How is this solved with
LiveTyping?

El jue, 9 de abr de 2026, 22:22, Hernán Wilkinson <
hernan.wilkinson at 10pines.com> escribió:

> just a small comment, with LiveTyping this is easily solved  😉
>
> On Wed, Apr 8, 2026 at 3:43 PM Juan Vuletich via Cuis-dev <
> cuis-dev at lists.cuis.st> wrote:
>
>> 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 Vuletichwww.cuis.stgithub.com/jvuletichresearchgate.net/profile/Juan-Vuletichindependent.academia.edu/JuanVuletichpatents.justia.com/inventor/juan-manuel-vuletich
>>>
>>>
>> --
>> Juan Vuletichwww.cuis.stgithub.com/jvuletichresearchgate.net/profile/Juan-Vuletichindependent.academia.edu/JuanVuletichpatents.justia.com/inventor/juan-manuel-vuletich
>>
>> --
>> Cuis-dev mailing list
>> Cuis-dev at lists.cuis.st
>> https://lists.cuis.st/mailman/listinfo/cuis-dev
>>
>
>
> --
>
> *Hernán WilkinsonAgile Software Development, Teaching & Coaching*
> *Phone: +54-011*-4893-2057
> *Twitter: @HernanWilkinson*
> *site: http://www.10Pines.com <http://www.10pines.com/>*
> Address: Alem 896, Floor 6, Buenos Aires, Argentina
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20260409/68a451a8/attachment-0001.htm>