Kevin Smith wrote:
It's opaque. If you self-hosted using a Uint32Array of length
two (e.g.), you'd have to declare that as the per-instance
state for the value class. I didn't show syntax for that --
working on it still.
And if you for some reason used floats (let's say for complex32,
with real and imag of float32 type), you'd get the recursive ===
full glory, including NaN !== NaN and -0 === 0.
Cool.
So it seems we have three notions of equality at play. If you'll
allow me to invent some terms:
A: type-identical equality
B: type-compatible equality
C: interpretive equality
Or loose or sloppy equality, apt metaphors (I won't elaborate).
A is expressed with "===". B is what we get with "==" when one of the
operands in a value object. C is what we get with "==" in all other
cases.
A and B are useful definitions of equality. I would argue that, for a
general-purpose programming language (i.e. not e.g. ColdFusion), C is
not useful. It's dangerous, in fact, because it's difficult for the
programmer to mentally keep track of the possible error paths that
could arise when interpretation is involved.
Value objects will naturally guide users toward "==", which could
possibly open up those error paths when the operand types are not
locally controlled.
So basically what I'm saying is, can we slay C? : )
There's a lot of == usage out there (Google codesearch went away, but
last I looked when it was still up).
It would be better to repair == by allowing developers to opt string and
boolean (note lowercase) into B, thereby making it an error to use an
object with a string or boolean as other operand. That seems doable with
value objects, although it wants declarative syntax.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
