[Cuis-dev] Add abstract method SystemWindow>>#buildMorphicWindow

Wed Apr 8 12:00:53 PDT 2026

Hi folks!

We stumbled on this issue as well. It's an interesting problem to think
about. The following is what I believe could be a fun idea to explore.

We came to the conclusion that the root of this issue is that windows might
be assuming two roles: the window itself and the object responsible to
compose it.

Separating these roles in two different objects (say SystemWindow  +
MyWindowBuilder) removes the need to have #buildMorphicWindow in
SystemWindow.

Currently, builders are "inlined" and implemented using the subclass
machinery by overriding #buildMorphicWindow (not a separate object).

Whether a separate object is a good fit/justified or makes sense is another
thing to think about and probably will depend on many things :)

Cheers!
Nico PM

On Wed, Apr 8, 2026, 15:42 Juan Vuletich via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> Hi Facu,
>
> (inline)
> On 2026-04-07 4:34 PM, Facundo Javier Gelatti via Cuis-dev wrote:
>
> This is very interesting! I think what you say makes sense.
>
> You leave me thinking about that distinction (i.e. a method that we
> strongly expect to be there, vs. a method that *could* be there for
> completeness, but which is not really necessary). I guess this is something
> I don't think too much about when I consider the "type" of an object (i.e.
> which messages it should be able to correctly understand). I think I tend
> to view each message as either part or not part of the expected protocol,
> not something in between (like "maybe/probably part of the protocol").
>
> I think that there are several protocols that a class may provide. Some
> maybe subsets of others. #buildMorphicWindow is part of an expanded
> protocol that only some windows provide.
>
>
> Other things that I have in my mind:
>
>    - I'm not sure if we should have another marker for these "nice to
>    have" messages. My first reaction is "no", just because we'd be adding more
>    elements to think about in the system; but then I come back to the original
>    distinction, which is something we should think about anyway (even if
>    implicitly)!
>    - One concrete "middle ground" in this case could be to implement
>    SystemWindow>>#buildMorphicWindow as an empty method, maybe with a comment
>    mentioning that it's just a non-essential extension point which *could*
>    be overridden by subclasses (but it's not necessary to do so to have e.g.
>    #open:label: work, etc.).
>
> Having #buildMorphicWindow as an empty method is not good IMO because it
> can hide the problem. We want _some_ exception. A DNU is better than just
> continue silently. But I like the idea of a middle ground. In this case, I
> implemented and called #subclassOptionalResponsibility. A reasonable error
> message plus some comments may be a good solution. Please take a look, it
> is now at GitHub.
>
>
> I hope my comments make sense (mostly things to ponder, we don't
> necessarily need to act on them right now).
>
> Of course they do. This kind of discussion is great, it enables polishing
> the system!
>
>
> Cheers!
> Facu
>
> Cheers!
>
>
> El mar, 7 abr 2026 a las 15:39, Juan Vuletich (<juan at jvuletich.org>)
> escribió:
>
>> Hi Facu,
>>
>> I don't like adding a send to #subclassResponsibility in the abstract
>> class in this case. #subclassResponsibility is a strong assertion from
>> the system that all subclasses should reimplement that method. It is a
>> message directed to any developer adding a new subclass. And in this
>> case, that's not true. There are subclasses that don't need that method
>> at all. It is true, #open:label: will fail. That only means that
>> #open:label: is not appropriate for them. Adding the call to
>> #subclassResponsibility would not change this fact.
>>
>> Hope this makes sense to you.
>>
>> Thanks,
>>
>> On 2026-04-02 4:14 PM, Facundo Javier Gelatti via Cuis-dev wrote:
>> > The #buildMorphicWindow message is sent from SystemWindow class >>
>> > #open:label:, and the method is on many window classes on the system,
>> > so I thought it'd be nice to have the abstract method in SystemWindow.
>> > I attach a (very small) change that adds that method.
>> >
>> > I also noticed this method is missing in TranscriptWindow,
>> > WorkspaceWindow and PreDebugWindow, so the #open:label: message is
>> > failing on those classes. I'm not sure what we should do about them.
>> >
>> > 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
>>
>>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20260408/11eedb6a/attachment.htm>