Es-discuss - several decimal discussions

Brendan Eich brendan at mozilla.org
Thu Sep 4 00:37:21 PDT 2008


On Sep 4, 2008, at 12:29 AM, David-Sarah Hopwood wrote:

> 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.

Straw man -- Ajax library authors have to object-detect, they do it  
as needed. We can't predict the future, so why worry? The point is  
that Object.eq could be done now or later. There's no imperative to  
do it now, with or without Decimal. Whatever the mix of Decimal and  
Object.eq, library authors can and must cope -- since they'll face  
downrev browsers.


> 2. This only accounts for Decimal, not for any other future types  
> where
>     === might not be an identity comparison.

Accounting for the future is not a reason to add an API that can be  
self-hosted (and will be, for older browsers).


> 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.

We haven't agreed on X, Y depends on X, therefore Y is not ready to  
spec -- yup, you're right. That doesn't mean we must add Object.eq  
now just to future-proof (even within the "future" that's before 3.1  
is done!). Cart Horse, ahead of.


> 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?

Are you familiar with requirements management, scheduling? It was not  
the last addition that made us late. It was not the last cookie I ate  
that made me fat.


> 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.

Or we do it next time and use the self-hosted version in the mean time.

You are trying to construct an absolute argument on relative terms. I  
could do that to add a large number of good APIs to 3.1 but then we'd  
be done in 2011. But if we keep arguing, we'll miss the chance to fix  
what's wrong in the current draft spec, so I'm going to stop here --  
have the last word if you like.


> 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'.

Ok.

/be



More information about the Es-discuss mailing list