[Cuis-dev] Add abstract method SystemWindow>>#buildMorphicWindow
Juan Vuletich
juan at jvuletich.org
Sat Apr 11 17:56:30 PDT 2026
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 <http://www.cuis.st>
>>> github.com/jvuletich <http://github.com/jvuletich>
>>> researchgate.net/profile/Juan-Vuletich
>>> <http://researchgate.net/profile/Juan-Vuletich>
>>> independent.academia.edu/JuanVuletich
>>> <http://independent.academia.edu/JuanVuletich>
>>> patents.justia.com/inventor/juan-manuel-vuletich
>>> <http://patents.justia.com/inventor/juan-manuel-vuletich>
>>>
>>>
>> --
>> Juan Vuletich
>> www.cuis.st <http://www.cuis.st>
>> github.com/jvuletich <http://github.com/jvuletich>
>> researchgate.net/profile/Juan-Vuletich <http://researchgate.net/profile/Juan-Vuletich>
>> independent.academia.edu/JuanVuletich <http://independent.academia.edu/JuanVuletich>
>> patents.justia.com/inventor/juan-manuel-vuletich <http://patents.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 Vuletich
> www.cuis.st
> github.com/jvuletich
> researchgate.net/profile/Juan-Vuletich
> independent.academia.edu/JuanVuletich
> patents.justia.com/inventor/juan-manuel-vuletich
--
Juan Vuletich
www.cuis.st
github.com/jvuletich
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20260411/40d6ce00/attachment-0001.htm>
More information about the Cuis-dev
mailing list