domenic at domenicdenicola.com (2013-11-03T22:03:17.047Z)
Tristan Zajonc wrote:
> Is this bug related to operator overloading? It seems just the nature
> of the beast with mutable reference types. Pretty much all JS matrix
> libraries today use:
>
> ```js
> if (mutMatA.equals(mutMatB)) {
> accidentallyMutate(mutMatA);
> assumeStillEqual(mutMatA, mutMatB, data);
> }
> ```
>
> which I assume would suffer from the same bug?
You bet, but special forms exist to have primitive semantics, which can
be meta-programmed only in certain ways (we try to preserve certain
invariants). With .equals, anything goes. With == where both operands
are object references, there has been an invariant. Allowing operator
customization to break that invariant might be worth the downside, but
it deserves discussion.
Tristan Zajonc wrote: > > if (mutMatA == mutMatB) { > accidentallyMutate(mutMatA); > assumeStillEqual(mutMatA, mutMatB, data); > } > > > Is this bug related to operator overloading? It seems just the nature > of the beast with mutable reference types. Pretty much all JS matrix > libraries today use: > > if (mutMatA.equals(mutMatB)) { > accidentallyMutate(mutMatA); > assumeStillEqual(mutMatA, mutMatB, data); > } > > which I assume would suffer from the same bug? You bet, but special forms exist to have primitive semantics, which can be meta-programmed only in certain ways (we try to preserve certain invariants). With .equals, anything goes. With == where both operands are object references, there has been an invariant. Allowing operator customization to break that invariant might be worth the downside, but it deserves discussion. /be