On Aug 23, 2008, at 5:45 PM, [EMAIL PROTECTED] wrote: > 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?
It forces would-be Decimal users to call Decimal.add(Decimal.parse(s) + 3) (let's say s may or may not be 2 or "2"). Is that a solution for ES3.1? It's user-hostile instead of future-hostile. Can we not do better, especially by not overconstraining the problem by subjecting its solution to the ES3.1 goals and schedule? > 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. I've been through as many what-if's and might-have-been's as anyone. JS clearly had too much implicit magic -- Perl-envy, if you will -- to be as neatly extensible as we want, in hindsight. EIBTI, the Pythonistas say. But this need not mean explicit method calls instead of operators for any numeric extension, since that's pretty much unusable (except under SOX mandate :-/). We've often cited EIBTI in ES4 working group meetings. In general I daresay the TC39 committee is more in favor of avoiding implicit magic, especially conversions, now than ever (E4X, ECMA-357, is full of it, and it's a mess). But this doesn't mean that throwing when a Decimal is used in any not-guaranteed-to-be-numeric operand context is good. >> 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? That's incompatible, and the double-dispatched (for dyadic operators) method mapping is something we'd like to avoid in the future (wherefore multimethods). > 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. BigMistake, as Cameron blogged. Java failed, C# ruled here. > I think the Java analogue is instructive. In Java, primitives and > objects are distinct. That's a botch, one I copied in a hurry in 1995 and regret. I should have stuck to the Self and Smalltalk sources of inspiration, but JS had to "look like Java" and it was easier both to implement, and to think about JS/Java bridging (LiveConnect, so-called), if I distinguished primitive string, boolean, and number from their object wrapper types. > BigDecimal was apparently a clumsy enough entity > that it was found to need implementation as a constructed object. This "apparently" backward-reasoning phenomenology is flawed. Implementors can work harder so programmers don't have to. There's no technical reason that decimal has to be a non-primitive in any language that distinguishes primitive types from first-class object types, any more than there is for strings to be non-primitive. > 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. What extensive planning do you mean? Oh, the lack of it when I created JS. Sorry, this is bogus arguing too :-|. Five-year plans are no guarantee of success. Utopia is not an option. Lots of underused languages have over-planned designs and nevertheless have big problems (other than lack of users). Anyway, languages that do succeed in gaining users inevitably grow. Growing a language is hard but possible. Python grew, including in its numeric model and operators. In spite of harsher backward compatibility constraints, so too can JS. IEEE double is not the only conceivable number type, and indeed 32- bit int and unsigned int show through in places in JS (bitwise operators, array length). I'm not in favor of more machine types. But I think making more BigMistakes with methods only, no operators, is guaranteed to keep IEEE double the only number type that's actually used by most real-world JS programmers. /be _______________________________________________ Es-discuss mailing list Es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
