[Cuis-dev] Add abstract method SystemWindow>>#buildMorphicWindow
Juan Vuletich
juan at jvuletich.org
Sat Apr 11 17:54:19 PDT 2026
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20260411/4d7d08de/attachment-0001.htm>
More information about the Cuis-dev
mailing list