Re: svn commit: r901058 - /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/NumberConverters.java
Alrighty then. For those less-jaded developers in the community, here is a good explanation of why we should use a currency (or money) class in the project: http://martinfowler.com/ap2/quantity.html -Adrian --- On Wed, 1/20/10, David E Jones wrote: > It might be simpler, but still not simple. Polymorphism is > nice and all (especially if you are enamored with spending > long hours reading confusing code, or if you area looking > for a way to fix a bad design with a worse one). There are > certainly good uses for it, usually when it is part of an > initial design (well, that's obviously just my opinion). > > The problem with polymorphism is object creation. This is > why factory methods have been so popular, but really even > those are often not adequate and you need a factory > interface with a configurable implementation (like I did for > the initial ExecutionContextFactory, and yeah I'll be > proposing that we change the static method factory approach > in the current branch to the factory interface approach). > > So, consider how many places we create BigDecimal objects. > That's where we have hundreds of lines of changes. Yes, once > a child object is created we can fool other code (since Sun > was nice enough to not make BigDecimal a final class like > String is). However, we still have to change all of the "new > BigDecimal(...)" and "BigDecimal.ZERO" and other similar > references. The arithmetic also gets tricky because any > non-Currency BigDecimal objects floating around that are on > the left side of the operation will result in a BigDecimal > instead of a Currency object for the result. Maybe this time > around (if someone REALLY wants to do this) we should > introduce a factory interface, or at least a factory static > method somewhere, so that NEXT time we decide to change it > all we'll at least avoid this problem. Of course, then we'll > also have to make sure everyone uses the factory and not > directly create the objects. These are all simple problems, > right? We may have to have dozens or hundreds of such > problems to deal with whenever writing this sort of code in > Java, but at least they are all simple ones! It's a good > thing that humans are not generally prone to error. > > So yeah, we're in 2010 and object-oriented programming has > been around for decades and has clearly won out over COBOL. > I have zero experience with COBOL, but all I have to say to > new object-oriented programmers, after using it for a decade > and a half with half a dozen different programming > languages, is... welcome to hell! :) Oh, and remember to > learn the dozens of work-arounds to weaknesses in the OO > concept, and of course all of the fancy names for those > work-arounds so you can impress everyone, oh and never call > them work-arounds... they are either "patterns" or "best > practices" depending on how aloof you want to appear. > > Of course, with such things said to the proverbial new > object-oriented programmer, I'm sure I am coming across as a > jaded, grumpy fart... and I left out the word "old" because > I've got at least another 30 years of work ahead of me > before I can claim the full honorary title of jaded, grumpy, > old fart. > > -David > > > On Jan 20, 2010, at 8:54 AM, Adrian Crum wrote: > > > You're a good sport. ;-) > > > > Seriously though, if anyone in the project wanted to > tackle it - I believe that approach will solve a lot of > problems. And I believe the code conversion would be a lot > simpler than the Double to BigDecimal change that was done a > while ago. > > > > Getting back to Scott's concern - I doubt this commit > will break anything. Most conversions in OFBiz supply a > Locale instance - which calls a different method than the > source object's toString() method. So, the returned String > will be formatted correctly. > > > > -Adrian > > > > > > --- On Wed, 1/20/10, David E Jones > wrote: > > > >> From: David E Jones > >> Subject: Re: svn commit: r901058 - > /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/NumberConverters.java > >> To: dev@ofbiz.apache.org > >> Date: Wednesday, January 20, 2010, 1:38 AM > >> > >> What's this "polymorphism" thing you're talking > about? I > >> guess I just haven't been around object-oriented > programming > >> for long enough. > >> > >> -David > >> > >> > >> On Jan 20, 2010, at 2:18 AM, Adrian Crum wrote: > >> > >>> David, > >>> >
Re: svn commit: r901058 - /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/NumberConverters.java
It might be simpler, but still not simple. Polymorphism is nice and all (especially if you are enamored with spending long hours reading confusing code, or if you area looking for a way to fix a bad design with a worse one). There are certainly good uses for it, usually when it is part of an initial design (well, that's obviously just my opinion). The problem with polymorphism is object creation. This is why factory methods have been so popular, but really even those are often not adequate and you need a factory interface with a configurable implementation (like I did for the initial ExecutionContextFactory, and yeah I'll be proposing that we change the static method factory approach in the current branch to the factory interface approach). So, consider how many places we create BigDecimal objects. That's where we have hundreds of lines of changes. Yes, once a child object is created we can fool other code (since Sun was nice enough to not make BigDecimal a final class like String is). However, we still have to change all of the "new BigDecimal(...)" and "BigDecimal.ZERO" and other similar references. The arithmetic also gets tricky because any non-Currency BigDecimal objects floating around that are on the left side of the operation will result in a BigDecimal instead of a Currency object for the result. Maybe this time around (if someone REALLY wants to do this) we should introduce a factory interface, or at least a factory static method somewhere, so that NEXT time we decide to change it all we'll at least avoid this problem. Of course, then we'll also have to make sure everyone uses the factory and not directly create the objects. These are all simple problems, right? We may have to have dozens or hundreds of such problems to deal with whenever writing this sort of code in Java, but at least they are all simple ones! It's a good thing that humans are not generally prone to error. So yeah, we're in 2010 and object-oriented programming has been around for decades and has clearly won out over COBOL. I have zero experience with COBOL, but all I have to say to new object-oriented programmers, after using it for a decade and a half with half a dozen different programming languages, is... welcome to hell! :) Oh, and remember to learn the dozens of work-arounds to weaknesses in the OO concept, and of course all of the fancy names for those work-arounds so you can impress everyone, oh and never call them work-arounds... they are either "patterns" or "best practices" depending on how aloof you want to appear. Of course, with such things said to the proverbial new object-oriented programmer, I'm sure I am coming across as a jaded, grumpy fart... and I left out the word "old" because I've got at least another 30 years of work ahead of me before I can claim the full honorary title of jaded, grumpy, old fart. -David On Jan 20, 2010, at 8:54 AM, Adrian Crum wrote: > You're a good sport. ;-) > > Seriously though, if anyone in the project wanted to tackle it - I believe > that approach will solve a lot of problems. And I believe the code conversion > would be a lot simpler than the Double to BigDecimal change that was done a > while ago. > > Getting back to Scott's concern - I doubt this commit will break anything. > Most conversions in OFBiz supply a Locale instance - which calls a different > method than the source object's toString() method. So, the returned String > will be formatted correctly. > > -Adrian > > > --- On Wed, 1/20/10, David E Jones wrote: > >> From: David E Jones >> Subject: Re: svn commit: r901058 - >> /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/NumberConverters.java >> To: dev@ofbiz.apache.org >> Date: Wednesday, January 20, 2010, 1:38 AM >> >> What's this "polymorphism" thing you're talking about? I >> guess I just haven't been around object-oriented programming >> for long enough. >> >> -David >> >> >> On Jan 20, 2010, at 2:18 AM, Adrian Crum wrote: >> >>> David, >>> >>> You were born two decades too late. You would have >> made a great COBOL programmer. >>> >>> Thanks to object oriented programming and >> polymorphism, existing code will think it is using a >> BigDecimal. >>> >>> >>> -Adrian >>> >>> >>> --- On Wed, 1/20/10, David E Jones >> wrote: >>>> 16 lines plus how many hundreds of changed lines >> and >>>> non-backwards compatible code? >>>> >>>> And how is 16 lines easier than inserting 5 >> characters that >>>> h
Re: svn commit: r901058 - /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/NumberConverters.java
You're a good sport. ;-)
Seriously though, if anyone in the project wanted to tackle it - I believe that
approach will solve a lot of problems. And I believe the code conversion would
be a lot simpler than the Double to BigDecimal change that was done a while ago.
Getting back to Scott's concern - I doubt this commit will break anything. Most
conversions in OFBiz supply a Locale instance - which calls a different method
than the source object's toString() method. So, the returned String will be
formatted correctly.
-Adrian
--- On Wed, 1/20/10, David E Jones wrote:
> From: David E Jones
> Subject: Re: svn commit: r901058 -
> /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/NumberConverters.java
> To: dev@ofbiz.apache.org
> Date: Wednesday, January 20, 2010, 1:38 AM
>
> What's this "polymorphism" thing you're talking about? I
> guess I just haven't been around object-oriented programming
> for long enough.
>
> -David
>
>
> On Jan 20, 2010, at 2:18 AM, Adrian Crum wrote:
>
> > David,
> >
> > You were born two decades too late. You would have
> made a great COBOL programmer.
> >
> > Thanks to object oriented programming and
> polymorphism, existing code will think it is using a
> BigDecimal.
> >
> >
> > -Adrian
> >
> >
> > --- On Wed, 1/20/10, David E Jones
> wrote:
> >> 16 lines plus how many hundreds of changed lines
> and
> >> non-backwards compatible code?
> >>
> >> And how is 16 lines easier than inserting 5
> characters that
> >> have none of the above problems?
> >>
> >> -David
> >>
> >>
> >> On Jan 20, 2010, at 1:29 AM, Adrian Crum wrote:
> >>
> >>> Was that reply supposed to make sense?
> >>>
> >>> Not ridiculous in 16 lines:
> >>>
> >>> @SuppressWarnings("serial")
> >>> public class Currency extends BigDecimal {
> >>> protected final
> com.ibm.icu.util.Currency
> >> currency;
> >>>
> >>> public Currency(Double
> value, String
> >> isoCode) {
> >>>
> super(value);
> >>>
> this.currency =
> >> com.ibm.icu.util.Currency.getInstance(isoCode);
> >>> }
> >>>
> >>> �...@override
> >>> public String
> toString() {
> >>>
> >> com.ibm.icu.text.NumberFormat format =
> >> ibm.ibm.icu.text.DecimalFormat.getInstance();;
> >>>
> >> format.setCurrency(this.currency);
> >>> return
> >> format.format(this);
> >>> }
> >>> }
> >>>
> >>> -Adrian
> >>>
> >>>
> >>>
> >>> --- On Tue, 1/19/10, David E Jones
> >> wrote:
> >>>
> >>>> From: David E Jones
> >>>> 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, 11:17 PM
> >>>>
> >>>> 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
>
> >>>> wrote:
> >>>>>
> >>>>>> From: David E Jones
> >>>>>> 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 c
Re: svn commit: r901058 - /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/NumberConverters.java
What's this "polymorphism" thing you're talking about? I guess I just haven't
been around object-oriented programming for long enough.
-David
On Jan 20, 2010, at 2:18 AM, Adrian Crum wrote:
> David,
>
> You were born two decades too late. You would have made a great COBOL
> programmer.
>
> Thanks to object oriented programming and polymorphism, existing code will
> think it is using a BigDecimal.
>
>
> -Adrian
>
>
> --- On Wed, 1/20/10, David E Jones wrote:
>> 16 lines plus how many hundreds of changed lines and
>> non-backwards compatible code?
>>
>> And how is 16 lines easier than inserting 5 characters that
>> have none of the above problems?
>>
>> -David
>>
>>
>> On Jan 20, 2010, at 1:29 AM, Adrian Crum wrote:
>>
>>> Was that reply supposed to make sense?
>>>
>>> Not ridiculous in 16 lines:
>>>
>>> @SuppressWarnings("serial")
>>> public class Currency extends BigDecimal {
>>> protected final com.ibm.icu.util.Currency
>> currency;
>>>
>>> public Currency(Double value, String
>> isoCode) {
>>> super(value);
>>> this.currency =
>> com.ibm.icu.util.Currency.getInstance(isoCode);
>>> }
>>>
>>> @Override
>>> public String toString() {
>>>
>> com.ibm.icu.text.NumberFormat format =
>> ibm.ibm.icu.text.DecimalFormat.getInstance();;
>>>
>> format.setCurrency(this.currency);
>>> return
>> format.format(this);
>>> }
>>> }
>>>
>>> -Adrian
>>>
>>>
>>>
>>> --- On Tue, 1/19/10, David E Jones
>> wrote:
>>>
>>>> From: David E Jones
>>>> 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, 11:17 PM
>>>>
>>>> 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
>>>> wrote:
>>>>>
>>>>>> From: David E Jones
>>>>>> 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
>>>>>> wrote:
>>>>>>>
>>>>>>>> From: Scott Gray
>>>>>>>> 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
Re: svn commit: r901058 - /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/NumberConverters.java
David,
You were born two decades too late. You would have made a great COBOL
programmer.
Thanks to object oriented programming and polymorphism, existing code will
think it is using a BigDecimal.
-Adrian
--- On Wed, 1/20/10, David E Jones wrote:
> 16 lines plus how many hundreds of changed lines and
> non-backwards compatible code?
>
> And how is 16 lines easier than inserting 5 characters that
> have none of the above problems?
>
> -David
>
>
> On Jan 20, 2010, at 1:29 AM, Adrian Crum wrote:
>
> > Was that reply supposed to make sense?
> >
> > Not ridiculous in 16 lines:
> >
> > @SuppressWarnings("serial")
> > public class Currency extends BigDecimal {
> > protected final com.ibm.icu.util.Currency
> currency;
> >
> > public Currency(Double value, String
> isoCode) {
> > super(value);
> > this.currency =
> com.ibm.icu.util.Currency.getInstance(isoCode);
> > }
> >
> > @Override
> > public String toString() {
> >
> com.ibm.icu.text.NumberFormat format =
> ibm.ibm.icu.text.DecimalFormat.getInstance();;
> >
> format.setCurrency(this.currency);
> > return
> format.format(this);
> > }
> > }
> >
> > -Adrian
> >
> >
> >
> > --- On Tue, 1/19/10, David E Jones
> wrote:
> >
> >> From: David E Jones
> >> 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, 11:17 PM
> >>
> >> 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
> >> wrote:
> >>>
> >>>> From: David E Jones
> >>>> 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
> >>>> wrote:
> >>>>>
> >>>>>> From: Scott Gray
> >>>>>> 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 t
Re: svn commit: r901058 - /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/NumberConverters.java
16 lines plus how many hundreds of changed lines and non-backwards compatible
code?
And how is 16 lines easier than inserting 5 characters that have none of the
above problems?
-David
On Jan 20, 2010, at 1:29 AM, Adrian Crum wrote:
> Was that reply supposed to make sense?
>
> Not ridiculous in 16 lines:
>
> @SuppressWarnings("serial")
> public class Currency extends BigDecimal {
>protected final com.ibm.icu.util.Currency currency;
>
>public Currency(Double value, String isoCode) {
>super(value);
>this.currency = com.ibm.icu.util.Currency.getInstance(isoCode);
>}
>
>@Override
>public String toString() {
>com.ibm.icu.text.NumberFormat format =
> ibm.ibm.icu.text.DecimalFormat.getInstance();;
>format.setCurrency(this.currency);
>return format.format(this);
>}
> }
>
> -Adrian
>
>
>
> --- On Tue, 1/19/10, David E Jones wrote:
>
>> From: David E Jones
>> 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, 11:17 PM
>>
>> 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
>> wrote:
>>>
>>>> From: David E Jones
>>>> 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
>>>> wrote:
>>>>>
>>>>>> From: Scott Gray
>>>>>> 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
>>>&g
Re: svn commit: r901058 - /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/NumberConverters.java
Was that reply supposed to make sense?
Not ridiculous in 16 lines:
@SuppressWarnings("serial")
public class Currency extends BigDecimal {
protected final com.ibm.icu.util.Currency currency;
public Currency(Double value, String isoCode) {
super(value);
this.currency = com.ibm.icu.util.Currency.getInstance(isoCode);
}
@Override
public String toString() {
com.ibm.icu.text.NumberFormat format =
ibm.ibm.icu.text.DecimalFormat.getInstance();;
format.setCurrency(this.currency);
return format.format(this);
}
}
-Adrian
--- On Tue, 1/19/10, David E Jones wrote:
> From: David E Jones
> 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, 11:17 PM
>
> 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
> wrote:
> >
> >> From: David E Jones
> >> 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
> >> wrote:
> >>>
> >>>> From: Scott Gray
> >>>> 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
> >>>> wrote:
> >>>>>
> >>>>>> From: Scott Gray
> >>>>>> 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, a
Re: svn commit: r901058 - /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/NumberConverters.java
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 wrote:
>
>> From: David E Jones
>> 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
>> wrote:
>>>
>>>> From: Scott Gray
>>>> 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
>>>> wrote:
>>>>>
>>>>>> From: Scott Gray
>>>>>> 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>>>>> String> {
>>>>>>> +public static class
>>>> BigDecimalToString
>>>>>> extends
>> AbstractToNumberConverter>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>
>
>
Re: svn commit: r901058 - /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/NumberConverters.java
Why?
--- On Tue, 1/19/10, David E Jones wrote:
> From: David E Jones
> 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
> wrote:
> >
> >> From: Scott Gray
> >> 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
> >> wrote:
> >>>
> >>>> From: Scott Gray
> >>>> 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 >>>> String> {
> >>>>> + public static class
> >> BigDecimalToString
> >>>> extends
> AbstractToNumberConverter >> 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
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
>
>
Re: svn commit: r901058 - /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/NumberConverters.java
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 wrote:
>
>> From: Scott Gray
>> 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
>> wrote:
>>>
>>>> From: Scott Gray
>>>> 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>>> String> {
>>>>> +public static class
>> BigDecimalToString
>>>> extends AbstractToNumberConverter> 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
>>>
>>>
>>>
>>
>>
>
>
>
Re: svn commit: r901058 - /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/NumberConverters.java
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 wrote:
> From: Scott Gray
> 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
> wrote:
> >
> >> From: Scott Gray
> >> 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 >> String> {
> >>> + public static class
> BigDecimalToString
> >> extends AbstractToNumberConverter 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
> >
> >
> >
>
>
Re: svn commit: r901058 - /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/NumberConverters.java
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 wrote:
>
>> From: Scott Gray
>> 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> String> {
>>> +public static class BigDecimalToString
>> extends AbstractToNumberConverter
>> {
>>> 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
>
>
>
smime.p7s
Description: S/MIME cryptographic signature
Re: svn commit: r901058 - /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/NumberConverters.java
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 wrote:
> From: Scott Gray
> 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 String> {
> > + public static class BigDecimalToString
> extends AbstractToNumberConverter
> {
> > 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
Re: svn commit: r901058 - /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/NumberConverters.java
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 {
> +public static class BigDecimalToString extends
> AbstractToNumberConverter {
>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
smime.p7s
Description: S/MIME cryptographic signature
