<div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000;text-align: left" dir="ltr">
Hi Jakob,<div><br></div><div>thanks for summarizing our arguments. :-) I would rather try to avoid another preference just to configure this preference. ;-) Maybe we can keep the uniform appearance for clickable text actions. I am surprised that DoItActions look different.</div><div><br></div><div>Hey Christoph,</div><div><br></div><div>a simple list of exclusions is not complex. Especially since it reflects stable language (and system) properties. I do appreciate your onward pursue of "perfect consistency." However, the system is full of trade-offs because it serves a rather broad audience.</div><div><br></div><div>I am also in favor of visual consistency for this feature. By only showing it for actually interesting object structures, we actually achieve consistency for those structures. Having it also for primitives would spoil the usefulness of this feature. <span style="font-size: 10pt">People might think they found something interesting -- to then be disappointed that it is just a flat string.</span></div><div><span style="font-size: 10pt"><br></span></div><div><span style="font-size: 10pt">Optimizing this feature for MCVersionName?! A domain-specific subclass of String? Well, I consider this design rather unfortunate. In such a case, on might be better of to favor composition over inheritance. That's an anti-pattern. Please do not do that in your projects. :-) ... I suspect an optimization for a database ... not sure. Chris?</span></div><div><span style="font-size: 10pt"><br></span></div><div><span style="font-size: 10pt">Hi all,</span></div><div><span style="font-size: 10pt"><br></span></div><div><span style="font-size: 10pt">here is again the list of objects I think we should exclude from having a text action on their print-it result:</span></div><div><span style="font-size: 10pt"><br></span></div><div><div>ByteString</div><div>ByteSymbol</div><div>Number</div><div>Boolean</div><div>UndefinedObject</div></div><div><br></div><div>If you find concrete arguments (and examples) against elements on this list, please step forward and name them. :-)</div><div><span style="font-size: 10pt"><br></span></div><div><span style="font-size: 10pt">Reducing visual clutter is worth a few lines of extra source code.</span></div><div><span style="font-size: 10pt"><br></span></div><div><span style="font-size: 10pt">Best,</span></div><div><span style="font-size: 10pt">Marcel</span></div><div><span style="font-size: 10pt"><br></span></div><div class="mb_sig"></div>
<blockquote class="history_container" type="cite" style="border-left-style: solid;border-width: 1px;margin-top: 20px;margin-left: 0px;padding-left: 10px;min-width: 500px">
<p style="color: #AAAAAA; margin-top: 10px;">Am 24.04.2021 15:42:08 schrieb Thiede, Christoph <christoph.thiede@student.hpi.uni-potsdam.de>:</p><div style="font-family:Arial,Helvetica,sans-serif">
<div dir="ltr">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size: 12pt;color: #000000;font-family: Calibri,Helvetica,sans-serif">
<p>Hi Jakob, Hi Marcel,</p>
<p><br>
</p>
<p>thank you for reviving this discussion! :-)</p>
<p><br>
</p>
<p>> <span style="font-size: 12pt">Christoph, when you inspect your MCVersionNames, do you already know </span><span style="font-size: 12pt">that these are version names or do you inspect them to find out what </span><span style="font-size: 12pt">they are? ("What
is this, a String or an MCVersionName?")</span></p>
<div><br>
</div>
<div>Definitively also the latter.</div>
<div><br>
</div>
<div>> <span style="font-size: 12pt">While the type check might not be really n</span><span style="font-size: 12pt">ecessary, avoiding visual clutter can be a good thing.</span></div>
<div><span style="font-size: 12pt"><br>
</span></div>
<div><span style="font-size: 12pt">-1 from my side here. :-) I see little value in adding complexity - and possibly confusion - in order to "simplify" the appearance - in my opinion, the clutter would become even larger if in some cases, the result is blue,
and in other cases, it isn't. I would rank (visual) consistency the highest here. We are introducing an additional classification here ("is primitive/is literal/is non-sense?") that is non-trivial as we can see from this discussion, and such heuristics feels
a little bit like "too much AI" for a general-purpose system like Squeak/Smalltalk, at least to me.</span></div>
<div><span style="font-size: 12pt"><br>
</span></div>
<div><span style="font-size: 12pt">> </span><span style="font-size: 12pt">How about allowing to turn off the highlighting of the result? I mean, </span><span style="font-size: 12pt">make it still clickable, but do not paint it blue.</span></div>
<div><span style="font-size: 12pt"><br>
</span></div>
<div><span style="font-size: 12pt">This might be a trade-off for me, but on the other hand, the logic is still cluttered. And the explorability is impeded ...</span></div>
<div><span style="font-size: 12pt"><br>
</span></div>
<div><span style="font-size: 12pt">Best,</span></div>
<div><span style="font-size: 12pt">Christoph</span></div>
<p></p>
<div id="x_Signature">
<div id="x_divtagdefaultwrapper" dir="ltr" style="font-size: 12pt;color: rgb(0,0,0);font-family: Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols">
<div name="x_divtagdefaultwrapper" style="font-family: Calibri,Arial,Helvetica,sans-serif;font-size: ;margin: 0">
<div><span style="font-size: 10pt;color: #808080"></span></div>
</div>
</div>
</div>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><span style="font-family: Calibri, sans-serif;color: #000000"><b>Von:</b> Squeak-dev <squeak-dev-bounces@lists.squeakfoundation.org> im Auftrag von Jakob Reschke <jakres+squeak@gmail.com><br>
<b>Gesendet:</b> Samstag, 24. April 2021 11:43:06<br>
<b>An:</b> The general-purpose Squeak developers list<br>
<b>Betreff:</b> Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz</span>
<div> </div>
</div>
</div>
<span style="font-size: 10pt"><span style="font-size: 10pt">
<div class="PlainText">Hi Christoph, hi Marcel,<br>
<br>
Am Di., 20. Apr. 2021 um 08:58 Uhr schrieb Marcel Taeumel<br>
<marcel.taeumel@hpi.de>:<br>
><br>
> Hi Christoph,<br>
><br>
> > [...] subclasses of ByteString can be indeed non-trivial. This applies to MCVersionName, for example<br>
><br>
> You are mixing up object structure with structured information. The latter needs interpretation by some other means. Squeak's inspector cannot provide such means of interpretation such as for URLs in strings.<br>
><br>
<br>
I am struggling to understand how your arguments address each other<br>
person's concerns. Did I understand your points correctly:<br>
<br>
- Christoph wants to get rid of the type check. He argues that<br>
sometimes even for the objects with "primitive" structure you may want<br>
to get the link. For example, MCVersionName loses its type information<br>
when printed, so when you would inspect the result, you would get a<br>
String instead of an MCVersionName. The other example is when you want<br>
to track identity. Indeed, sometimes it is useful to check whether one<br>
String is the same as another one retrieved (inspected) from somewhere<br>
else. I do this regularly in Squot when debugging the capturing and<br>
materialization (although seldom for Strings at this time because for<br>
these it already works as expected).<br>
<br>
- Marcel says that the links are unnecessary for what are essentially<br>
value objects that are not complex enough to need inspection beyond<br>
just looking at the print string. Supposedly, one can just reevaluate<br>
the result or the expression. Adding the links there produces visual<br>
clutter and is distracting. Inspecting an MCVersionName would reveal<br>
no further information about the object than the print string does<br>
(that is, except for the type!).<br>
<br>
Christoph, when you inspect your MCVersionNames, do you already know<br>
that these are version names or do you inspect them to find out what<br>
they are? ("What is this, a String or an MCVersionName?")<br>
<br>
I fully agree with Marcel on the immediates and singletons (true,<br>
false, nil, Symbols). While the type check might not be really<br>
necessary, avoiding visual clutter can be a good thing. Tradeoff is<br>
with having the special case in the code.<br>
<br>
Unfortunately(?), Strings in Squeak/Smalltalk are not quite value<br>
objects, since they are mutable, can be used as buffers, etc. Depends<br>
on the application.<br>
<br>
On the other hand, Points are mostly used as value objects, but did<br>
not get the special case treatment. Though strictly, technically<br>
speaking, they are not different from Strings in this regard.<br>
<br>
Inspecting the result string or the revaluating the original<br>
expression to do so is only safe if it does not provoke side effects.<br>
For Marcel's selection of classes, there are no side effects of<br>
reevaluating the result string. But reevaluating the original<br>
expression might not be free of side effects. I guess you would not<br>
reevaluate the expression to inspect an immediate or singleton, but<br>
for those objects that do have object identity, such as Strings, or<br>
where the type of the result is not obvious, MCVersionName, you might<br>
want to do that.<br>
<br>
How about allowing to turn off the highlighting of the result? I mean,<br>
make it still clickable, but do not paint it blue. Then there would be<br>
no visual clutter, and if you know that the feature is there (and you<br>
have subsequently turned off the preference, for example), you would<br>
also not easily forget that you can use it.<br>
<br>
Kind regards,<br>
Jakob<br>
<br>
</div>
</span></span>
</div></blockquote></div>