Re: [Joda-money-interest] feedback and a couple of suggestions

[Gareth D. <ga...@lo...>]

On 19 Nov 2009, at 08:17, Stephen Colebourne wrote:

> 2009/11/18 Gareth Davis <ga...@lo...>:
>> Money/BigMoney
>> ==============
>> Looks a little confusing, not sure if this is just mid refactoring... but only one would be fine (backed by BigDecimal)
> 
> The classes have different purposes and APIs. Money fixes the decimal
> places to the currencies scale, BigMoney can have any scale.
> 
ah... I see it kinda of looks at first glance that BigMoney is meant to be a higher capacity implementation of Money. It may just be a naming issue...VariableScaleMoney, Maybe Money should just be a interface and you could have flavours FixedScaleMoney & VariableScaleMoney  - ZeroScaleMoney (some applications actually do have that policy) 

> 
>> Money#equals(Object)
>> ====================
>> Currently is scale aware i.e. USD 30 != USD 30.00 this really isn't representative of real monetary amounts and is one of the reasons that using a raw BigDecimal for monetary amounts is a pain. I would suggest that if the Money represents the same amount of a currency it is equal to another regardless of the internal scale (ie. be based on BigDecimal#compareTo)
>> 
>> The gotcha with this is that the hashCode of BigDecimal as includes the scale.
> 
> Money has a fixed scale, so this doesn't occur as an issue.
> 
> For BigMoney its more of a problem. I have defined equals as "you can
> take this object and replace it by an equals() object and see no
> changes in your application". I like that definition.
> 
I see ... it a little problematic. BigMoney's divide operations are I guess the issue, they assume the scale of the of the current object which would be where it could break if the above was implemented. The alternate is to make the divide operations have a mandatory scale parameter, when ever dividing money. I realise this is different to BigDecimal, but again it's one of the reasons why BigDecimal isn't the best thing for money values.

I think the principle of least surprise would indicate that USD 10 == USD 10.00? It doesn't for BigDecimal and the number of bugs caused by it is huge.


>> Zero money
>> ==========
>> This is a more radical suggestion and that is that zero doesn't have a currency. This may seem completely nuts but bare with me. The reasoning for this is quite simple in the real world nothing is well nothing, if somebody has 0 pounds... it is exactly the same.
> 
> I'll have to spend longer thinking about this...
> 
it a bit controversial this one, I'm by no means 100% certain that it's correct but I've also seen painful null handling in several real applications that have currencies in zero. Maybe views from a  wider audience would help.

>> PS I have a couple of patches for the current trunk (just compile stuff) would you like them posted to this list?
> 
2902028 - JDK 1.6 compile fix is one of mine
2899206 - Is a dup of the other patch I was going to submit. Although I'd suggest the compiler config is moved to a profile rather than deleted.

> Patches are best as tracker issues in the sourceforge tracker.
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Joda-money-interest mailing list
> Jod...@li...
> https://lists.sourceforge.net/lists/listinfo/joda-money-interest