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 _______________________________________________ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
