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 <[email protected]> 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 <[email protected]> > wrote: > > > >> From: David E Jones <[email protected]> > >> Subject: Re: svn commit: r901058 - > /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/NumberConverters.java > >> To: [email protected] > >> 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 <[email protected]> > >> 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 > <[email protected]> > >>>> wrote: > >>>>> > >>>>>> From: David E Jones <[email protected]> > >>>>>> Subject: Re: svn commit: r901058 > - > >>>> > >> > /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/NumberConverters.java > >>>>>> To: [email protected] > >>>>>> 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 > >> <[email protected]> > >>>>>> wrote: > >>>>>>> > >>>>>>>> From: David E Jones <[email protected]> > >>>>>>>> Subject: Re: svn commit: > r901058 > >> - > >>>>>> > >>>> > >> > /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/NumberConverters.java > >>>>>>>> To: [email protected] > >>>>>>>> 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 <[email protected]> > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> From: Scott Gray > <[email protected]> > >>>>>>>>>> Subject: Re: svn > commit: > >> r901058 > >>>> - > >>>>>>>> > >>>>>> > >>>> > >> > /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/NumberConverters.java > >>>>>>>>>> To: [email protected] > >>>>>>>>>> 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 <[email protected]> > >>>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> From: > Scott Gray > >> <[email protected]> > >>>>>>>>>>>> Subject: > Re: svn > >> commit: > >>>> r901058 > >>>>>> - > >>>>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >> > /ofbiz/trunk/framework/base/src/org/ofbiz/base/conversion/NumberConverters.java > >>>>>>>>>>>> To: [email protected] > >>>>>>>>>>>> Date: > Tuesday, > >> January 19, > >>>> 2010, > >>>>>> 9:16 PM > >>>>>>>>>>>> On > 19/01/2010, at > >> 9:36 PM, > >>>> [email protected] > >>>>>>>>>>>> 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 > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>> > >>> > >>> > >> > >> > > > > > > > >
