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

Tue Apr 14 11:11:56 PDT 2026

great!! thanks :-)

On Sat, Apr 11, 2026 at 9:56 PM Juan Vuletich <juan at jvuletich.org> wrote:

> BTW, saved it with your author initials.
>
> Cheers!
> On 2026-04-11 9:54 PM, Juan Vuletich wrote:
>
> Hi Hernán,
>
> Points taken. Just pushed your suggestion to GitHub.
>
> Thanks!
> On 2026-04-10 7:35 PM, Hernán Wilkinson via Cuis-dev wrote:
>
> 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 Wilkinson Agile 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
>
> --
> 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
>
>

-- 

*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/20260414/0cea2fca/attachment-0001.htm>