[Cuis-dev] Other potentially missing abstract methods

Hernán Wilkinson hernan.wilkinson at 10pines.com
Fri Apr 10 12:38:52 PDT 2026


It will help when sending a message that it is not implemented, as in the
case of #buildMorphicWindow, or #rotation: sent in Morph>>#rotationDegrees:
(see examples below) The type checker shows those errors.
It will not help when the message is sent in subclasses but not implemented
in the superclass.
[image: image.png]
[image: image.png]


On Thu, Apr 9, 2026 at 10:36 PM Facundo Javier Gelatti <
javiergelatti at gmail.com> wrote:

> 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
>>
>

-- 

*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/20260410/4a48e94c/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 208172 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20260410/4a48e94c/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 174418 bytes
Desc: not available
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20260410/4a48e94c/attachment-0003.png>


More information about the Cuis-dev mailing list