On Wed, Dec 15, 2010 at 11:07 AM, nicolas.o...@gmail.com <nicolas.o...@gmail.com> wrote: >> Again, there'd have to be a staggering further benefit from the change >> than just "the clojure.core code looks cleaner in github" or even "the >> code is a bit easier to maintain in the future". I'm not sure that >> even massive increases in code maintainability alone suffice for >> something like this. A major, massively end-user-useful new feature >> that's nigh-impossible to implement otherwise that can then be >> implemented *might* suffice. > > I think the point was not to criticize you at all (nobody have to read > every post in the archive) > but just to point the fact that this debate was somehow already behind us.
Perhaps so, but if so, this pointing-out was done in a manner that was open to interpretation. > It has been already debated a lot with pretty good points on each > side. (The concerns you are expressing > are good points, as are the answers in this thread and the preceeding > on the subject.) What answers in this thread? The points I'm aware of so far are: Pros (heard from others so far and taken on faith): * Clojure's code base can be made internally simpler. * It's easier to implement what was already implemented. (?) * Code that isn't performance-critical may get slightly faster. Cons: (easily inferred from what's been stated) * Code that is performance-critical won't get any faster but will need to be rewritten. * It may even get slower if there's no way to get the old unchecked-foo behavior where overflows wrap rather than throw OR get promoted. * Everything else may break randomly from time to time if not rewritten. * Ugly tick-marks will appear after every arithmetic operator in ordinary code. * Or else ugly Ns after every numeric literal in ordinary code. * Or else it breaks randomly from time to time. * Non-backward-compatible semantic changes affecting nearly every existing sourcefile! I can only assume, in the spirit of interpreting these events charitably, that there may be a pro or two not on my list. :) But that means that those pros were not raised in this thread. You said the answers in this thread are good points, but the second pro on my list is damned dubious, the third is clearly not worth wrecking backward compatibility, and I'm highly dubious of the notion that the first is, or even all three of those combined. > For the specific problem you are facing, I would advise to go through > your code looking for number literal and > replacing each number nnnn by nnnnN. (ex 15 ---> 15N). > > As boxedness is contagious, you probably won't have to change much > more to solve compatibility issues with 1.3. > > If you find other specific problems, it would be great to post them: > we will need a good compilation of tips to convert numerical code from > 1.2 to 1.3. Thanks. I'll keep this in mind if I'm ever forced to upgrade to 1.3. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
