Brendan Eich wrote:
> On Aug 24, 2008, at 10:02 PM, Mark S. Miller wrote:
>
>> Let's say you did that -- make a special case for NaN but not for -0.
>> Let's say you use this Map to build memoize. Now let's say someone
>> writes a purely functional function F such that F(0) is 3 and F(-0) is
>> 7. Let's say G is memoize(F). Would you find it acceptable for G(0) to
>> sometimes yield 3 and sometimes 7?
>
> I'd file a bug, or find a better memoizer :-). "Quality of
> implementation" eager beavers can use Math.atan2 to tell -0 from 0,
> just as they can use isNaN or x !== x.
>
> Yes, this is gross. I'm in favor of Object.identical and
> Object.hashcode, maybe even in ES3.1 (I should get my act together
> and help spec 'em).
In the absence of decimal, Object.eq is trivial to spec:
Object.eq(NaN, NaN) = true
Object.eq( 0, -0) = false
Object.eq( -0, 0) = false
Object.eq( x, y) = (x === y), otherwise.
or to implement:
Object.eq = function (x, y) {
if (x === y) {
return x !== 0 || 1/x === 1/y;
} else {
return x !== x && y !== y;
}
};
> Just not particularly on account of Decimal, even
> with equated cohort members.
If there is a possibility that we are ever going to add decimal (or other
types for which === might not be an identity test), then adding Object.eq
now allows writing future-proof code for such things as memoizers --
whatever the semantics of === for decimals (or between decimals and
other numbers) turns out to be.
--
David-Sarah Hopwood
_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
