brendan at mozilla.com
Thu Jan 16 11:06:10 PST 2014
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.
> 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
> 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.
More information about the es-discuss