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 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> >>> >>> >> >> > > >
