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

> - C: interpretive equality

Or loose or sloppy equality, apt metaphors (I won't elaborate).

> 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.