Equality Reform(ul)ation
I would expect that to be true same as 0 == {valueOf:Number} would be
js> 0L == { valueOf: function() { return 0 } }
typein:2:0 TypeError: no operator function found for ==
Is the Object-type operand converted to a primitive before the overload is matched?
No, the multimethod dispatch algorithm runs. Even with ToObject (I see I left that out), there is no predefined @@ADD or @@ADD_R on Object.prototype, so the error above is inevitable.
Andrea Giammarchi wrote:
I would expect that to be
truesame as0 == {valueOf:Number}would be
No, please do read what I posted. Value object operator dispatch is different and does not use toString or valueOf on an object operand.
What's the method for determining whether we run the multimethod dispatch algorithm versus the ES6 abstract equality algorithm?
Apologies if the answer is already out there.
Kevin Smith wrote:
What's the method for determining whether we run the multimethod dispatch algorithm versus the ES6 abstract equality algorithm?
One or both operands value objects.
Apologies if the answer is already out there.
No need to apol., you have exceeded my slideware neo-spec ;-).
One or both operands value objects.
Gotcha. One more, I think.
int64(0) === 0L
I assume that int64 is not defined as a composition of primitives or value objects. How do we know the above to be true? Are they somehow the same (value) object reference?
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").
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).
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.
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.
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?
- 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.
Brendan Eich wrote:
It would be better to repair == by allowing developers to opt string and boolean (note lowercase) into B
And number too.
Will try to get all this drafted, just not today.
And what does this do?
Is the Object-type operand converted to a primitive before the overload is matched?
> > >> js> 0L == "0" >> typein:2:0 TypeError: no operator function found for == >> > > And what does this do? 0L == { valueOf() { return 0 } } Is the Object-type operand converted to a primitive before the overload is matched? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140115/4955682f/attachment.html>