[squeak-dev] The Inbox: Morphic-ct.1586.mcz

Thiede, Christoph Christoph.Thiede at student.hpi.uni-potsdam.de
Sat Apr 24 13:41:53 UTC 2021


Hi Jakob, Hi Marcel,


thank you for reviving this discussion! :-)


> Christoph, when you inspect your MCVersionNames, do you already know that these are version names or do you inspect them to find out what they are? ("What is this, a String or an MCVersionName?")

Definitively also the latter.

> While the type check might not be really necessary, avoiding visual clutter can be a good thing.

-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.

> How about allowing to turn off the highlighting of the result? I mean, make it still clickable, but do not paint it blue.

This might be a trade-off for me, but on the other hand, the logic is still cluttered. And the explorability is impeded ...

Best,
Christoph

________________________________
Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im Auftrag von Jakob Reschke <jakres+squeak at gmail.com>
Gesendet: Samstag, 24. April 2021 11:43:06
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] The Inbox: Morphic-ct.1586.mcz

Hi Christoph, hi Marcel,

Am Di., 20. Apr. 2021 um 08:58 Uhr schrieb Marcel Taeumel
<marcel.taeumel at hpi.de>:
>
> Hi Christoph,
>
> > [...]  subclasses of ByteString can be indeed non-trivial. This applies to MCVersionName, for example
>
> 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.
>

I am struggling to understand how your arguments address each other
person's concerns. Did I understand your points correctly:

- Christoph wants to get rid of the type check. He argues that
sometimes even for the objects with "primitive" structure you may want
to get the link. For example, MCVersionName loses its type information
when printed, so when you would inspect the result, you would get a
String instead of an MCVersionName. The other example is when you want
to track identity. Indeed, sometimes it is useful to check whether one
String is the same as another one retrieved (inspected) from somewhere
else. I do this regularly in Squot when debugging the capturing and
materialization (although seldom for Strings at this time because for
these it already works as expected).

- Marcel says that the links are unnecessary for what are essentially
value objects that are not complex enough to need inspection beyond
just looking at the print string. Supposedly, one can just reevaluate
the result or the expression. Adding the links there produces visual
clutter and is distracting. Inspecting an MCVersionName would reveal
no further information about the object than the print string does
(that is, except for the type!).

Christoph, when you inspect your MCVersionNames, do you already know
that these are version names or do you inspect them to find out what
they are? ("What is this, a String or an MCVersionName?")

I fully agree with Marcel on the immediates and singletons (true,
false, nil, Symbols). While the type check might not be really
necessary, avoiding visual clutter can be a good thing. Tradeoff is
with having the special case in the code.

Unfortunately(?), Strings in Squeak/Smalltalk are not quite value
objects, since they are mutable, can be used as buffers, etc. Depends
on the application.

On the other hand, Points are mostly used as value objects, but did
not get the special case treatment. Though strictly, technically
speaking, they are not different from Strings in this regard.

Inspecting the result string or the revaluating the original
expression to do so is only safe if it does not provoke side effects.
For Marcel's selection of classes, there are no side effects of
reevaluating the result string. But reevaluating the original
expression might not be free of side effects. I guess you would not
reevaluate the expression to inspect an immediate or singleton, but
for those objects that do have object identity, such as Strings, or
where the type of the result is not obvious, MCVersionName, you might
want to do that.

How about allowing to turn off the highlighting of the result? I mean,
make it still clickable, but do not paint it blue. Then there would be
no visual clutter, and if you know that the feature is there (and you
have subsequently turned off the preference, for example), you would
also not easily forget that you can use it.

Kind regards,
Jakob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210424/a73048cf/attachment.html>


More information about the Squeak-dev mailing list