> Kevin Smith <mailto:zenparsing at gmail.com>
> January 16, 2014 8:26 AM
> [oops - reply all this time]
>
>     Value objects have value, not reference, semantics. JS has string
>     number boolean already (note lowercase names). With value objects,
>     users and the host env can define others.
>
>
> Makes sense, but I thought the user could not define semantics for 
> "===":  it just means "===" for each of its data members ("structural 
> recursive strict equality test").

For integer types such as int32 and uint64, it's important that === be a 
bit-compare.
>
> Does that mean that the host is somehow able to define "===" semantics 
> for opaque value types (like int64)?  Again, I'm assuming that int64 
> is opaque (i.e. not visibly composed of other elements).

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.

/be

> Makes sense, but I thought the user could not define semantics for 
> "===":  it just means "===" for each of its data members ("structural 
> recursive strict equality test").

For integer types such as int32 and uint64, it's important that === be a 
bit-compare.

> Does that mean that the host is somehow able to define "===" semantics 
> for opaque value types (like int64)?  Again, I'm assuming that int64 
> is opaque (i.e. not visibly composed of other elements).

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.