On Sat, Aug 23, 2008 at 11:30 AM, Sam Ruby <[EMAIL PROTECTED]> wrote: > Having Decimal.parse(2) + 3 produce "23" is not what I would call "fail > fast", as that is a term I would typically use for throwing an exception or > the like.
Point well taken. Does Maciej's followup regarding valueOf throwing solve the problem? > At most, Sarbanes-Oxley might be an example of one source for requirements. It's even weaker than that -- my suspicion (admittedly in ignorance) is that SOX does not inform us directly regarding interoperation of numerics in ES or elsewhere. :) Yet as a programmer, I would feel much better if I know that my carefully controlled arithmetic automatically checks for the silly mistakes I could make (especially under ES's dynamic typing). Removing problematic implicit conversions and comparisons with native numerics could be one way to achieve that. > I don't believe the concerns are that decimals are a "same enough" or a > "different enough beast", but rather that "fail fast" is not the type of > behavior one would expect from ES for numeric operations. Were ES designed, back in 1995, to be the language it has become, and were there time back then to have thought about how the builtin arithmetic and comparison generalizes to mixtures of decimals, arbitrary precision integers, complex numbers, matrices and polynomials, I would agree with you unequivocally. As matters stand, I'm not so sure. > It would not be wise for equality operators, in particular, to > start throwing exceptions. Could these operators simply be consistent with "===" for any user defined library type, and something else (a ".equals()" operator, say) be used to define value equality? Once again, Java faced this same problem in adding BigDecimal -- and Java is strongly typed and so arguably had more leeway to add rules that make it clearer to programmers what was going on. Yet their solution was to simply create classes at the library level. I think the Java analogue is instructive. In Java, primitives and objects are distinct. BigDecimal was apparently a clumsy enough entity that it was found to need implementation as a constructed object. In ES, everything is an object yet there are primitive types; this means that, when faced with a newly required constructed object type, we are tempted to slip it in as a new primitive. In the absence of extensive planning done back in the mid 1990s, I submit that the temptation is to be resisted. Ihab -- Ihab A.B. Awad, Palo Alto, CA _______________________________________________ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
