ES3.1 Draft: 22 Sep 2008 "Redmond" version available

David-Sarah Hopwood david.hopwood at industrial-designers.co.uk
Tue Sep 23 20:04:12 PDT 2008


Sam Ruby wrote:
> Brendan Eich wrote:
[...]
>> The intuition depends on string equality and ToString in addition to  
>> numeric equality. But it turns out that a === b for any numbers a and  
>> b implies ToString(a) === ToString(b) (except, again, for the very  
>> small numbers David Jones pointed out).
>>
>> But Sam's decimal implementation has 1.1m === 1.10m.
>>
>> So the precise issue with "breaks arrays" is the proposal from Sam  
>> and Mike that ToString on a decimal preserve scale digits (I hope I'm  
>> using the right term). That breaks the a === b => o[a] is o[b] rule  
>> that exists today (modulo tiny values) for numbers a and b, when  
>> extended to decimals a and b.
> 
> At the present time, strictly equals is approximately the "Object.eq". 
> There is no question that a.eq(b) => o[a] is o[b].
> 
> Permit me to be so bold as to propose a Gedanken Experiment?
> 
> Is it ever anticipated that future editions of ECMAScript will allow 
> users to provide via multimethods alternative implementations for either 
> double equals or triple equals?

'==': that would potentially be useful, and I wouldn't want to rule it
out at this stage (even though I'm not a particular fan of multimethods
as they are defined in existing languages).

Object.eq: no by definition. An EQ operation has a fixed semantics that
tests identity without consulting its arguments or being overridable
depending on their type.

'===': that depends whether we want '===' to continue to be an approximation
of EQ, with 0, -0, and NaN as the only special cases.

-- 
David-Sarah Hopwood


More information about the Es-discuss mailing list