Tangential to comparison is also the morphic copy methods.
What do we mean when we copy a complex object?

Best,
Karl



On Wed, Jan 11, 2023 at 5:40 PM Eliot Miranda <eliot.miranda at gmail.com>
wrote:

>
>
> On Jan 11, 2023, at 5:37 AM, Taeumel, Marcel <Marcel.Taeumel at hpi.de>
> wrote:
>
> 
> Hi Christoph --
>
> At this point, let's not fiddle with Text >> #=.
>
>
> +1
>
>
> I think that comparing sets of attributes with each other can be as tricky
> as comparing morphs, unless you restrict yourself to very simple emphasis
> (bold/italic/...).
>
> Identity-vs-state will bite you for "non-literal" attributes:
> - PluggableTextAttribute (i.e., compiled code, bindings, complex objects,
> ...)
> - TextFontReference (i.e., various font properties, form-set fonts, pixel
> comparison?, ...)
> - TextAnchor (i.e., morphs ...)
>
> Thus, the very mechanism of text properties is so flexible that
> implementing a useful comparison should be done on a case-by-case basis.
> For example, compare #runs if necessary and sufficient, as suggested in the
> comment in #=.
>
> Just comparing the identity of text attributes is not worth breaking
> backwards compatibility.
>
>
> +1
>
> I faced a similar issue when defining CompiledMethod >> #=.
> CompiledMethods hold onto their class via the method class association.  So
> if the same exact sequence of bytecodes and literals occurs in two methods
> but on different classes, comparing the method class associations will show
> them as different. But this kind of code duplication is often exactly what
> we want to identify. So CompiledMethod >> #= treats the method class
> associations comparison carefully; each method should have one or neither
> should.
>
> As a thought experiment let’s imagine one wanted to compare two Smalltalk
> images to find out where they differ. One could progress through the
> Smalltalk dictionary in alphabetic order and compare classes and globals.
> But classes refer to subclasses and superclasses, and methods, so the
> transitive closure from any class will include the Smalltalk dictionary.
> That’s not a serious issue; we can add a visited set to avoid looping in
> the comparison. But if equality does look deep into the structure, and not
> just at a surface string (eg of methods and inst var names & class vars)
> then *any* difference, say in the value of a global in Smalltalk (release
> id?) will mark any class as different, and that’s not very useful.  Instead
> we probably want to compare classes “skin deep” (do they have the same
> superclass name, inst var names, class vars, methods and organization) and
> then we have a chance of finding the much more specific difference.
>
> I know the text comparison issue is a little different. But the current
> definition is useful (after all the visual representation of a text is
> affected by the font and that’s not defined by the text itself (in our
> model)). And as Marcel says, one can always define a different one for
> special cases. And we have lots of precedence for that (isSameSequenceAs:
> et al).
>
> Equality is tricky. A given definition must be useful “in a general
> context” (hand waving I know), and must match #hash, and must be reasonably
> efficient to be usable.  All that implies that in non-trivial implements a
> good comment should be written :-)
>
> Happy ‘23!
>
>
> Best,
> Marcel
>
> Am 16.09.2020 16:44:07 schrieb Thiede, Christoph <
> christoph.thiede at student.hpi.uni-potsdam.de>:
>
> Hi Levente,
>
>
> hm, I think #= should be always commutative and transitive, everything
> else is at least confusing ...
>
>
> Can't we move that "attribute invariant" comparison rather to something
> like Text >> #sameAs:?
>
>
> Best,
>
> Christoph
> ------------------------------
> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
> Auftrag von Levente Uzonyi <leves at caesar.elte.hu>
> *Gesendet:* Mittwoch, 16. September 2020 15:00:28
> *An:* The general-purpose Squeak developers list
> *Betreff:* Re: [squeak-dev] FormInspector, or also: Text>>#= and its
> consequences
>
> Hi Christoph,
>
>
> On Wed, 16 Sep 2020, Thiede, Christoph wrote:
>
> >
> > Interesting, I would not have assumed that this would be only about
> performance, sounded like a more profound design decision to me.
>
> If you have a look at the comment of Text >> #=, you'll find that it's a
> design decision (no reasoning though):
>
> = other
>          "Am I equal to the other Text or String?
>          ***** Warning ***** Two Texts are considered equal if they have
> the same characters in them.  They might have completely different
> emphasis, fonts, sizes, text actions, or embedded morphs.  If you need to
> find out if one is a true copy of the other, you must do (text1 = text2
> and: [text1 runs = text2 runs])."
>
>
> Though equality with Strings is not symmetric;
>
> 'foo' asText = 'foo'. "==> true"
> 'foo' = 'foo' asText. "==> false"
>
> I don't know what relies on Text-String equality, but probably many things
> assume that Texts and Strings are somewhat interchangable (remember when
> you changed SHParserST80 >> #initializeVariablesFromContext, and Shout ran
> into errors because it expected source to be a String but got a Text?)
>
> You can't keep equality with Strings if you change #= because you'll lose
> transitivity:
>
> 'foo' asText allBold = 'foo'. "==> true"
> 'foo' asText = 'foo'. "==> true"
> 'foo' asText allBold = 'foo' asText "==> false"
>
>
> Should you decide to change #=, remember to change #hash as well, and
> rehash all hashed collections with text keys.
>
>
> Levente
>
> >
> >
> > If no one sees a problem in changing this behavior, I can try my luck.
> :-)
> >
> >
> > Best,
> >
> > Christoph
> >
> >
> __________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________
> > Von: Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
> Auftrag von Taeumel, Marcel
> > Gesendet: Dienstag, 15. September 2020 16:42:11
> > An: squeak-dev
> > Betreff: Re: [squeak-dev] FormInspector, or also: Text>>#= and its
> consequences
> > Hi Christoph.
> > Performance. Change it, bench it, post the results here. :-) Please
> specify you machine and try it on a slow RaspPi, too.
> >
> > Best,
> > Marcel
> >
> >       Am 10.09.2020 20:32:34 schrieb Thiede, Christoph <
> christoph.thiede at student.hpi.uni-potsdam.de>:
> >
> >       Hi all,
> >
> >
> >       is there any old thread about the design discussion of how
> Text>>#= works? (It does not consider attributes for quality.) Has this
> decision ever been questioned?
> >
> >
> >       Naively and without an overview of any existing components that
> could rely on this implementation, I would like to question it.
> >
> >       Why should 'foo' asText allBold be equal to 'foo' asText
> addAttribute: TextURL new? With the same logic, we could also say that two
> dictionaries are equal iff they have got the same keys ...
> >
> >
> >       There is even a concrete client in the Trunk suffering from this
> design decision: Marcel's new FormInspector (and analogously,
> MorphInspector). It uses
> >
> >       TextFontReference with a FormSetFont to display a screenshot right
> in the inspector pane. Unfortunately, the pane is never updated
> automatically because even if the screenshot changes, the text morph thinks
> the old text would equal the new one. I'd like to fix that without hacking
> any workaround into
> >       the inspectors.
> > Even though this inspector implementation is a bit unusual, in my
> opinion, it shows that the current Text >> #= implementation might not be a
> perfect solution.
> >
> > I'm looking forward to your opinions.
> >
> > Best,
> > Christoph
> >
> >
> >
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20230111/17fa56ab/attachment-0001.html>