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

Fri Apr 10 15:35:47 PDT 2026

Hi,
 I think that an important heuristic, or rule if you wish, of software
design is to avoid surprises, also known as "the principle of least
astonishment."
 When doing "SystemWindow open: aModel" opens the debugger with an MNU,
it's surprising because the first thing you think is that you made a
mistake... As far as I see it, MNU indicates an error, so I think it is
better not to get an MNU.
 Is it better to signal a subclassResponsibility or to do nothing? It will
depend: if it makes sense for the instance to exist, do nothing, if it does
not, signal a subclassResponsibility. In this case I think it is better to
implement #buildMorphicWindow to do nothing and write a comment stating
that subclasses can re define it if they want to add morphs at instance
creation time. Why? Because it makes sense to have system windows without
any morph, you can already do this by evaluating "SystemWindow new
openInWorld".
 What about #subclassOptionalResponsibility? Following the idea of the
previous phrase, I don't think adding this new message makes sense. As I
see it, this adds complexity and raises doubts, such as why it is
optional? when should I redefine it? etc

 I always try to make my classes easy to understand, consistent, and
helpful in showing how to use them without generating doubts. That is why
for example I only have one instance message that sends #new, the other
instance messages are defined based on the one that sends #new. I treat MNU
as an indication of an implementation error because it means I made a
mistake somewhere. Receiving an MNU during a normal execution path, as the
message #open: allows, is confusing from my point of view.

 Anyway, I think it is better in this case to implement #buildMorphicWindow
to do nothing, avoid surprises and document that you can redefine it if you
wish to add morphs when instantiating a subclass.

  In retrospect, it would be great to have these kinds of talks using
another medium :-) and maybe with a mate/coffe or a bear

Cheers!
Hernan.

On Wed, Apr 8, 2026 at 4:01 PM Nicolás Papagna Maldonado via Cuis-dev <
cuis-dev at lists.cuis.st> wrote:

> 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
>>
> --
> 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/20260410/7941c772/attachment.htm>