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

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?  : )

And if so, how?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140116/34ef5044/attachment.html>

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

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?  : )

And if so, how?