Split money

[jodastephen]

From https://sourceforge.net/u/jamiem/profile/
https://sourceforge.net/p/joda-money/feature-requests/1/

It would be useful to have a 'split' or 'divide' method like:
Money m = Money.of(CurrencyUnit.GB, 3.99d);
Money[] parts = m.split(4);
// where
// parts[0] == 1.00
// parts[1] == 1.00
// parts[2] == 1.00
// parts[3] == 0.99

[jodastephen]

I'm not sure that it is an important enough method to have in the core project however. For your case, why is it splitting by 1.00? In general, all these pieces of logic like split are quite specific to individual applications.

[gigs2go]

I used exactly this mechanism for a Subscription management system, and I think of it as a core mechanism for money handling. I used Fowler's algorithm e.g. (http://stackoverflow.com/questions/1679292/proof-that-fowlers-money-allocation-algorithm-is-correct), and it is used as the basis for a multi-million turnover system.
Basic question was where to put the 'last bits' - usually across the beginning or the end.
I'd be happy to implement it in joda-money (being a big fan of joda-time) ...

[jodastephen]

I appreciate the need for this now, and have a vague notion about how it might fit in.

My theory is that really what is needed is a Money class, with variable precision, and a parallel MoneyCalculator. The calculator can be setup with various rules (like rounding and precision). It then has methods to allow the money to be worked on. This algorithm is one that could be included. The hard part is that the set of algorithms is really variable based on appliction requirements. If the project picks one way, it might not be right for everyone.

In the meantime, it seems common enough to consider a split method on Money itself, especially if a pull request is forthcoming. I guess there is the fowler variant using ratios, and the one listed above, which may equate to the same thing but isn't specific.

[gigs2go]

I agree with your 'theory'.
I propose a calculator sub-package with a MoneyCalculatorBuilder and a MoneyCalculator interface. The default 'toCalculator' method will return a MoneyCalculator which will implement the various methods ... which will, in turn, be implemented by the objects injected into the Builder. This will allow 'out of the box' implementation with sub-classable configuration for specific purposes. A question would be : should the Calculator subsume/replace the Utils (and some of the Money) methods? I can propose the MoneyCalculator interface if you think this is a good way to go ...

[jodastephen]

See also #6, which is a very similar request.

I think any calculator would have a precision to which it calculates. It would have to keep a record of anything that gets lost along the way, although the detail of that wil be complex no doubt. I also think that the calculator probably should be mutable rather than immutable.

I'd like to see some ideas in this area, so if you feel like trying something, I say fork and go-ahead. I'm not sure how your builder fits in for example. I'd suggest writing it up as a prototype first, rather than a full ready to go pull request, so we can brainstorm around the problem.

I think the Utils are mostly null-checks, so not really the same thing. Most of the existing methods on Money are useful for one-shot changes - its the multi-step or harder calculations that need extra handling.

[gigs2go]

I'm new to git ...
I've put a very basic sketch into https://github.com/gigs2go/joda-money.git - but it seems to have been pushed to a 'money' directory in the top level of the Allocator branch.
Blush.
I think this illustrates the basic principle I was thinking of - even if it doesn't match yours :-) I can think of at least 4 more allocators which could be configured - and, of course, the hook is there for user-defined ones.
Adding arbitrary (and lossless) precision arithmetic ops (as per #6) could also go into the Calculator ... but then it would have to hold state and respond to a 'return result' call - not too difficult really. And just like a real calculator!