> >>> There was another change to earlier today that you may be interested
> >> > in asking that question about too, since it changed 19-year old
> >> > SequenceableCollection>>#= with a one-day old replacement and actually
> >> > went into trunk.
> >>
> >> Please note that this has been discussed more than a month ago, and the discussion clearly converged to this consensus:
> >> - having Interval and Array being = is not an important feature
> >> - it seriously impacts efficiency of Interval hash
> >> - it causes long standing bugs that we carry for years (19 years or so)
> >
> > Yes, I remember that discussion.
> >
> >> What's the point of having Interval = Array, when we have OrderedCollection ~= Array at the same time?
> >> A less arbitrary feature would be a generalization of eachOperand isSequenceable ==> testThatElementsAreSameSequence:
> >> But it's both too hard to maintain (a bug factory), aand a problem for efficient implementation of some specialized collection.
> >> At the end, it's maybe not so much a desirable feature and it's practically not used in trunk images, apart for writing shorter tests.
> >> I'm not a big fan of C motto when used with extremism: you don't pay for what you don't buy.
> >> But I have the feeling that it makes sense here.
> >
> > I have no reason to critique this reasoning, I simply did not have
> > time to test with it yet.  Sometimes testing after tweaks at low
> > levels can "reveal" things that weren't thought about before.  But
> > also, what I really dislike are continued use == on the class test.
>
> What is the use case which doesn't work with the
>
>         foo class == bar class ifTrue: [ ... ]
>
> pattern?

Magma uses Avi Bryant's WriteBarrier which depends on that.  In the
example above, foo's and/or bar's class were replaced by an anonymous
subclass which WOULD compare #= to its superclass, if only the caller
wouldn't subvert its chance by using an identity test.

The result is at least the 2nd-worst type of application bug -- the
kind that execute incorrectly, but silently (hopefully not resulting
in corrupt data!  but possible..)

Guys, I used to sprinkle #== sends for "performance" too, a habit I
learned early-on, but development and use of Magma case gave me the
context to understand why its wrong from an OO perspective, and why
I'm pleading with you to readjust your development pattern on this.
Please only send #== when an identity check is actually needed (which
is almost never).  Doing it for "performance" ends up being very
destructive to Magma applications.

Best,
  Chris


  - Chris