Es-discuss - several decimal discussions
ihab.awad at gmail.com
ihab.awad at gmail.com
Sat Aug 23 17:45:33 PDT 2008
On Sat, Aug 23, 2008 at 11:30 AM, Sam Ruby <rubys at intertwingly.net> 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 A.B. Awad, Palo Alto, CA
More information about the Es-discuss