<div dir="ltr">Hi, <div> 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."</div><div> 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.</div><div> 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".</div><div> 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</div><div><br></div><div> 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.</div><div><br></div><div> 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.</div><div><br></div><div> In retrospect, it would be great to have these kinds of talks using another medium :-) and maybe with a mate/coffe or a bear </div><div><br></div><div>Cheers!</div><div>Hernan.</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, Apr 8, 2026 at 4:01 PM Nicolás Papagna Maldonado via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st">cuis-dev@lists.cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div>Hi folks!</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">Separating these roles in two different objects (say SystemWindow + MyWindowBuilder) removes the need to have #buildMorphicWindow in SystemWindow.</div><div dir="auto"><br></div><div dir="auto">Currently, builders are "inlined" and implemented using the subclass machinery by overriding #buildMorphicWindow (not a separate object).</div><div dir="auto"><br></div><div dir="auto">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 :)</div><div dir="auto"><br></div><div dir="auto">Cheers!</div><div dir="auto">Nico PM</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 8, 2026, 15:42 Juan Vuletich via Cuis-dev <<a href="mailto:cuis-dev@lists.cuis.st" target="_blank">cuis-dev@lists.cuis.st</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>
<div>
<p>Hi Facu,</p>
<p>(inline)</p>
<div>On 2026-04-07 4:34 PM, Facundo Javier
Gelatti via Cuis-dev wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div>This is very interesting! I think what you say makes
sense.</div>
<div><br>
</div>
<div>You leave me thinking about that distinction (i.e. a
method that we strongly expect to be there, vs. a method
that <i>could</i> 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").</div>
</div>
</div>
</blockquote>
<p>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.</p>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div><br>
</div>
<div>Other things that I have in my mind:<br>
<ul>
<li>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)!</li>
<li>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 <i>could</i>
be overridden by subclasses (but it's not necessary to
do so to have e.g. #open:label: work, etc.).</li>
</ul>
</div>
</div>
</div>
</blockquote>
<p>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.</p>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div><br>
</div>
<div>I hope my comments make sense (mostly things to ponder,
we don't necessarily need to act on them right now).</div>
</div>
</div>
</blockquote>
<p>Of course they do. This kind of discussion is great, it enables
polishing the system!</p>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">
<div><br>
</div>
<div>Cheers!</div>
<div>Facu</div>
<div><br>
</div>
</div>
</div>
</blockquote>
<p>Cheers!</p>
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">El mar, 7 abr 2026 a las
15:39, Juan Vuletich (<<a href="mailto:juan@jvuletich.org" rel="noreferrer" target="_blank">juan@jvuletich.org</a>>)
escribió:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi
Facu,<br>
<br>
I don't like adding a send to #subclassResponsibility in the
abstract <br>
class in this case. #subclassResponsibility is a strong
assertion from <br>
the system that all subclasses should reimplement that
method. It is a <br>
message directed to any developer adding a new subclass. And
in this <br>
case, that's not true. There are subclasses that don't need
that method <br>
at all. It is true, #open:label: will fail. That only means
that <br>
#open:label: is not appropriate for them. Adding the call to
<br>
#subclassResponsibility would not change this fact.<br>
<br>
Hope this makes sense to you.<br>
<br>
Thanks,<br>
<br>
On 2026-04-02 4:14 PM, Facundo Javier Gelatti via Cuis-dev
wrote:<br>
> The #buildMorphicWindow message is sent from
SystemWindow class >> <br>
> #open:label:, and the method is on many window classes
on the system, <br>
> so I thought it'd be nice to have the abstract method
in SystemWindow. <br>
> I attach a (very small) change that adds that method.<br>
><br>
> I also noticed this method is missing
in TranscriptWindow, <br>
> WorkspaceWindow and PreDebugWindow, so the #open:label:
message is <br>
> failing on those classes. I'm not sure what we should
do about them.<br>
><br>
> Cheers!<br>
> Facu<br>
><br>
-- <br>
Juan Vuletich<br>
<a href="http://www.cuis.st" rel="noreferrer noreferrer" target="_blank">www.cuis.st</a><br>
<a href="http://github.com/jvuletich" rel="noreferrer noreferrer" target="_blank">github.com/jvuletich</a><br>
<a href="http://researchgate.net/profile/Juan-Vuletich" rel="noreferrer noreferrer" target="_blank">researchgate.net/profile/Juan-Vuletich</a><br>
<a href="http://independent.academia.edu/JuanVuletich" rel="noreferrer noreferrer" target="_blank">independent.academia.edu/JuanVuletich</a><br>
<a href="http://patents.justia.com/inventor/juan-manuel-vuletich" rel="noreferrer noreferrer" target="_blank">patents.justia.com/inventor/juan-manuel-vuletich</a><br>
<br>
</blockquote>
</div>
</div>
<br>
<fieldset></fieldset>
</blockquote>
<pre cols="72">--
Juan Vuletich
<a href="http://www.cuis.st" rel="noreferrer" target="_blank">www.cuis.st</a>
<a href="http://github.com/jvuletich" rel="noreferrer" target="_blank">github.com/jvuletich</a>
<a href="http://researchgate.net/profile/Juan-Vuletich" rel="noreferrer" target="_blank">researchgate.net/profile/Juan-Vuletich</a>
<a href="http://independent.academia.edu/JuanVuletich" rel="noreferrer" target="_blank">independent.academia.edu/JuanVuletich</a>
<a href="http://patents.justia.com/inventor/juan-manuel-vuletich" rel="noreferrer" target="_blank">patents.justia.com/inventor/juan-manuel-vuletich</a></pre>
</div>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" rel="noreferrer" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div>
-- <br>
Cuis-dev mailing list<br>
<a href="mailto:Cuis-dev@lists.cuis.st" target="_blank">Cuis-dev@lists.cuis.st</a><br>
<a href="https://lists.cuis.st/mailman/listinfo/cuis-dev" rel="noreferrer" target="_blank">https://lists.cuis.st/mailman/listinfo/cuis-dev</a><br>
</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div style="font-size:small"><div dir="ltr"><div dir="ltr"><div style="font-size:12.8px"><span style="font-family:tahoma,sans-serif;font-size:xx-small;border-collapse:collapse"><strong><span style="font-size:8pt"><span style="font-size:small"><font size="2"><span style="font-weight:normal"><span style="font-weight:bold">Hernán Wilkinson</span><br>Agile Software Development, Teaching & Coaching</span></font></span></span></strong></span></div><div style="font-size:12.8px"><span style="font-family:tahoma,sans-serif;font-size:xx-small;border-collapse:collapse"><strong><span style="font-size:8pt"><span style="font-size:small"><font size="2"><span style="font-weight:normal">Phone: +54-011</span></font></span></span></strong></span><font face="tahoma, sans-serif" size="2">-4893-2057</font></div><div style="font-size:12.8px"><strong style="font-family:tahoma,sans-serif;font-size:xx-small"><span style="font-size:8pt"><span style="font-size:small"><font size="2"><span style="font-weight:normal">Twitter: @HernanWilkinson</span></font></span></span></strong></div><div style="font-size:12.8px"><span style="font-family:tahoma,sans-serif;font-size:xx-small;border-collapse:collapse"><strong><span style="font-size:8pt"><span style="font-size:small"><font size="2"><span style="font-weight:normal">site: <a href="http://www.10pines.com/" style="color:rgb(17,65,112)" target="_blank">http://www.10Pines.com</a></span></font></span></span></strong></span></div><div style="font-size:12.8px"><font face="tahoma, sans-serif"><span style="border-collapse:collapse">Address: Alem 896</span></font>, Floor 6, Buenos Aires, Argentina</div></div></div></div></div></div></div></div>