On Sun, Aug 24, 2008 at 11:13 AM, Brendan Eich <[EMAIL PROTECTED]> wrote: > On Aug 24, 2008, at 6:18 AM, Sam Ruby wrote: > >> A modest >> request: if the code could be reviewed and feedback provided to me >> with sufficient time for me to address the comments and the code to be >> integrated into a nightly build, by default disabled, in time for the >> Redmond meeting, I would appreciate it. > > Set the review flag to my bugzilla id -- othewise I won't see it in > my request queue, and I'll probably forget to go review it on my own. > Thanks.
I'll see if I can rev it first based on the changes we have been discussing and to resync with the latest hg TIP. Once that is done, I'll set the review flag. I was unclear on the process - thanks for the tip. >> Let's posit for the moment that adding two nickles and calling >> toString() on the result produces "1.10" > > Where'd the buck come from? ;-) Ok, I'm with you so far... > Oopsie! :-) >> Furthermore assume that 1.10m > 1.09m and that 1.10m < 1.11m. >> >> Given the above, as well as your knowledge of ES history, what would >> you expect the results of evaluating the following two expressions to >> be: >> >> 1.10m == 1.1m > > true. > >> 1.10m === 1.1m > > true, but there's a weak case for false if you really insist that the > significance is part of the value. If we make the result be false, > then people who advocate always using === instead of == to avoid > implicit conversions would be giving bad advice to Decimal users. I'm > sticking with true for the reason given below. That's the conclusion we came to. An argument could be made for either answer, but the stronger case, based on ES consistency, is for true. You correctly anticipated the followup question, and I address that below. But your mentioning of conversions triggers a different line of questions. What should the result of the following expressions be: 1.5m == 1.5 1.5m === 1.5 typeof(1.5m) A case could be made that both binary64 and decimal128 are both numbers, and that a conversion is required. A case could be made that while they are both numbers, the spec needs to retain the behavior that users have come to expect that conversions are not performed for strict equality. And finally, a case could be made that the result of typeof(1.5m) should be something different, probably "decimal", and that decimal128 values are never strictly equal to binary64 values, even when we are talking about simple integers. Whatever the conclusion, neither the spec updates nor the code updates would be difficult. >> Depending on your answers, there may be a followup question. > > Guy Steele, during ES1 standardization, pointed out that some Lisps > have five equality-like operators. This helped us swallow === and !== > (and keep the == operator, which is not an equivalence relation). > > Must we go to this well again, and with Object.eq (not an operator), > all just to distinguish the significance carried along for toString > purposes? Would it not be enough to let those who care force a string > comparison? I think that a "static" Decimal method (decNumber calls this compareTotal) would suffice. Others believe this needs to be generalized. I don't feel strongly on this, and am willing to go with the consensus. > /be - Sam Ruby _______________________________________________ Es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
