Tristan Zajonc wrote:
Having === be reference equality is fine if that's a hard JS
requirement. For a matrix API, there is some flexibility on
comparison operators, but transient value comparison returning a
single boolean is the most natural, other issues aside. I'm not sure I
fully understand the bug you're worried about though.
if (mutMatA == mutMatB) {
accidentallyMutate(mutMatA);
assumeStillEqual(mutMatA, mutMatB, data);
}
It's true that in JS today, comparing an object to a non-object, valueOf
or toString on the object can be used to make == results vary.
However, I'm proposing value objects with declarative syntax to solve
several problems:
1. Backward compatibility, so == uses cannot change unexpectedly on
extant code, or grow performance hair in existing engines facing
existing code.
2. Solve the cross-frame problem where loading the same value class
declaration results in the same typeof and other results for operations
on values instantiated from equivalent declarations (details still being
worked out).
3. Facilitate functional programming, both for user benefit and for
engines, which can better optimize based on immutable values (including
stack allocation).
A secondary issue, and probably a bigger can of worms, is
whether the proposal will allow for additional operators. For
matrices, there is a well-defined and established set of
operators that operate elementwise and objectwise (MATLABs
dot-operators vs. operators).
What punctuators or (non-ASCII?) lexemes would you want for these
operators?
I'd want every operator prefixed by something (dot, tilde, colon).
JS uses dot, tilde and colon. But let's not get stuck here. I suggest
that novel operator syntax needs a fresh thread, and that it should be
informed by the SweetJS experience so far.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
