Brendan Eich wrote:
> On Sep 3, 2008, at 11:15 PM, David-Sarah Hopwood wrote:
>
>> 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;
>> }
>> };
[shorter, but less clear code snipped]
> My point was that Decimal doesn't make the case particularly strong,
> since you just need to add Decimal.compareTotal:
>
> Object.eq = function (x, y) {
> if (x instanceof Decimal && y instanceof Decimal)
> return Decimal.compareTotal(x, y) == 0;
> return (x === y) ? x !== 0 || 1/x == 1/y : x !== x && y !== y;
> }
1. You can't do that in ES3.1 if Decimal is not in ES3.1. You'd have
to add "typeof Decimal !== 'undefined' &&" to the 'if' condition.
And then you'd be trying to anticipate a future spec, rather than
relying on an existing one.
2. This only accounts for Decimal, not for any other future types where
=== might not be an identity comparison.
3. It's not clear to me that this code is correct; at least not without
making assumptions about how === will work on mixed arguments that
have not yet been agreed. Will 1 === 1m be true (when decimals are
added)? If so, then Object.eq(1, 1m) as implemented above will be
true when it should be false.
> How much less trivial is this? Two lines, fewer with more ?: chaining.
The size of the code is irrelevant. Object.eq doesn't add significantly
to language complexity, and provides a useful basic operation, so why
shouldn't it be in the spec?
>> 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.
>
> JS developers have to cope with downrev browsers. There's no imperative
> "now" (ES3.1) vs. "next time", since they'll need something like the
> above as fallback for "last time" (ES3-based) browsers.
Unless they are targetting only ES3.1-and-above. At some point (maybe
several years) in the future, they'll be able to do that -- provided that
Object.eq was added in ES3.1.
> Again my point is to avoid mission creep in 3.1. I have no problem with
> identical and hashcode. If I'm wrong and they can be slipped in without
> any delay, filling inevitable latency in the current schedule, great.
>
> I should get busy on the spec.
>
> Ob. Bikeshed: You seem committed to eq as the name.
Not really, but eq has been used to refer to this operation for decades
in both the Lisp and capability communities. I can live with
Object.identical, but I'll always think of it as 'eq'.
--
David-Sarah Hopwood
_______________________________________________
Es-discuss mailing list
Es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
