Because it has nothing to do with the problem at hand. It's a diversion from what the priorities we are working with.
-David On Jan 20, 2010, at 12:25 AM, Adrian Crum wrote: > Why? > > > --- On Tue, 1/19/10, David E Jones <d...@me.com> wrote: > >> From: David E Jones <d...@me.com> >> Subject: Re: svn commit: r901058 - >> /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/NumberConverters.java >> To: dev@ofbiz.apache.org >> Date: Tuesday, January 19, 2010, 10:16 PM >> >> Sorry, that's ridiculous. >> >> -David >> >> >> On Jan 20, 2010, at 12:02 AM, Adrian Crum wrote: >> >>> If I was a scientist and I was using a BigDecimal for >> scientific calculations, then I would expect its String >> representation to be in scientific format. >>> >>> Maybe what sticks in your mind is what you expect >> currency to do. Currency is not the same as BigDecimal. If >> you are concerned that currency will be displayed in >> scientific notation, then maybe we should consider using a >> currency class for currency, instead of using BigDecimal. >>> >>> -Adrian >>> >>> --- On Tue, 1/19/10, Scott Gray <scott.g...@hotwaxmedia.com> >> wrote: >>> >>>> From: Scott Gray <scott.g...@hotwaxmedia.com> >>>> Subject: Re: svn commit: r901058 - >> /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/NumberConverters.java >>>> To: dev@ofbiz.apache.org >>>> Date: Tuesday, January 19, 2010, 9:51 PM >>>> If you don't think it will break >>>> anything then fine, feel free to work it however >> you >>>> like. Although I'd be surprised if many >> users expect a >>>> string representation of a number to be in >> scientific >>>> notation. >>>> >>>> The BigDecimal toString/toPlainString issue always >> sticks >>>> in my mind because it does exactly what I don't >> expect a >>>> toString method to do. >>>> >>>> Regards >>>> Scott >>>> >>>> On 19/01/2010, at 10:40 PM, Adrian Crum wrote: >>>> >>>>> Scott, >>>>> >>>>> Thank you for pointing that out. I think what >> I'm >>>> trying to achieve is predictable behavior from a >> user or >>>> developer's standpoint. >>>>> >>>>> Take an unknown Java object type and convert >> it to a >>>> String. As a developer, what would you expect the >> result to >>>> be? From my perspective it would be whatever the >> object's >>>> toString() method would return. >>>>> >>>>> Does that make sense? >>>>> >>>>> -Adrian >>>>> >>>>> --- On Tue, 1/19/10, Scott Gray <scott.g...@hotwaxmedia.com> >>>> wrote: >>>>> >>>>>> From: Scott Gray <scott.g...@hotwaxmedia.com> >>>>>> Subject: Re: svn commit: r901058 - >>>> >> /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/NumberConverters.java >>>>>> To: dev@ofbiz.apache.org >>>>>> Date: Tuesday, January 19, 2010, 9:16 PM >>>>>> On 19/01/2010, at 9:36 PM, adri...@apache.org >>>>>> wrote: >>>>>> >>>>>>> Author: adrianc >>>>>>> Date: Wed Jan 20 04:36:42 2010 >>>>>>> New Revision: 901058 >>>>>>> >>>>>>> URL: http://svn.apache.org/viewvc?rev=901058&view=rev >>>>>>> Log: >>>>>>> Simplified the number converters. >> Eliminated >>>> an >>>>>> unnecessary abstract class, made use of >> Java's >>>> auto-boxing. >>>>>> Non-localized Number to String conversions >> use the >>>> the >>>>>> toString() method - so the result is what >> you >>>> would expect. >>>>>>> >>>>>>> - public static class >>>> BigDecimalToString >>>>>> extends >>>> AbstractUsesLocaleConverter<BigDecimal, >>>>>> String> { >>>>>>> + public static class >>>> BigDecimalToString >>>>>> extends >> AbstractToNumberConverter<BigDecimal, >>>> String> >>>>>> { >>>>>>> >> public >>>> BigDecimalToString() >>>>>> { >>>>>>> >> >>>>>> super(BigDecimal.class, String.class); >>>>>>> } >>>>>>> >>>>>>> + public >> String >>>>>> convert(BigDecimal obj) throws >> ConversionException >>>> { >>>>>>> + >> >>>> return >>>>>> obj.toString(); >>>>>>> + } >>>>>>> + >>>>>> >>>>>> >>>>>> Hi Adrian, >>>>>> >>>>>> bigDecimal.toString() can return >> scientific >>>> notation in >>>>>> some cases, it's usually better to use >>>>>> bigDecimal.toPlainString() >>>>>> http://java.sun.com/javase/6/docs/api/java/math/BigDecimal.html#toString() >>>>>> >>>>>> Regards >>>>>> Scott >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> > > >