money
money copied to clipboard
Precise money
Adds PreciseMoney
. Fixes #7.
Few considerations before continuing:
- Is this the right path to start with?
- What to do with the PHP Calculator? It will have strange results when multiplying and dividing, so I left it out of the
PreciseMoney
calculators. However, I did implement some changes for tests to succeed (all floating number bug related changes).
What should be next?
- What to do with formatting and parsing? Do we want to support it at all?
- What to do with conversion? Do we want to support it at all?
- ...
Is this still active? I presume I am right in thinking that this is to allow us to perform operations using more decimal places? Ie GBP 1.1535 * 0.4251
etc?
@m4tthumphrey You can already do that.
new Money(11535, new Currency('GBP'));
new Money(4251, new Currency('GBP'));
You should implement your own currency with subunits set to 4. See the BitcoinCurrencies how to do this. If there are more currencies involved than only the pound, use the Aggregate Currencies class to turn multiple currencies it into a single repository.
PreciseMoney
could be used if you do not want to round your amounts. But as you can see, this branch has not been merged yet. Use at your own risk.
I was more enquiring than actually looking to use it!
I have just looked into the custom currencies and I see how it works now! Thanks!
Hello,
What's the status of this? Is it gonna be merged?
No progress. I expect to look at in the end of the year. If someone could give some feedback, that could - of course - help to have the feature earlier.
@sagikazarmark I am planning to update this PR. The considerations I mentioned earlier on are still valid.
Is this the right path? Meaning: should we create a new class PreciseMoney
that supports unlimited decimals? Or should we embed the functionality in Money
? The current solution is the former. However it has cons. First of all, we cannot reuse the formatters/parsers/currencies within PreciseMoney. But that is - of course - only a con if the domain requires the functionality. And there is a way of overcoming this by creating conversion methods: Money
<-> PreciseMoney
.
So the questions are?
- Create a new class
PreciseMoney
or embed inMoney
? - If answer is create a new class
PreciseMoney
, how to support formatters/parsers/currencies? - Should we create a
toMoney(int $decimals)
inPreciseMoney
? - Should we create a
toMoney(Currencies $currency)
method inPreciseMoney
? - Or should there be something like
PreciseToMoneyConverter
? - Or should be add methods to
Money
, likefromPreciseMoney()
? - What if
PreciseMoney
was not be currencies aware, soPreciseMoney = f(amount)
instead ofPreciseMoney = f(amount, currency)
?
My initial answers are as follows.
- Create a new class
PreciseMoney
or embed inMoney
?
New class
- If answer is create a new class
PreciseMoney
, how to support formatters/parsers/currencies?
Convert PreciseMoney to Money (one direction).
- Should we create a
toMoney(int $decimals)
inPreciseMoney
?
Yes
- Should we create a
toMoney(Currencies $currency)
method inPreciseMoney
?
No
- Or should there be something like
PreciseToMoneyConverter
?
No
- Or should be add methods to
Money
, likefromPreciseMoney()
?
No, we should add
fromMoney(Money $money): PreciseMoney
andtoMoney(int $decimals): Money
toPreciseMoney
only.Money
does not have to know the existence ofPreciseMoney
.
- What if
PreciseMoney
was not be currencies aware, soPreciseMoney = f(amount)
instead ofPreciseMoney = f(amount, currency)
?
Bad idea.
@sagikazarmark Could you emphasize your thoughts. Maybe just start with some initials thoughts. Then we will iterate towards the optimal solution.
Hi @frederikbosch.
Here at Mollie we think adding a PreciseMoney
type is a great idea, but you should not be able to convert from PreciseMoney
to Money
.
@willemstuursma Cool to see you drop in. Could you emphasize why we should not be able to convert to Money
? How to support formatters/parsers/currencies for PreciseMoney
without conversion possibility?
@frederikbosch Why don't you drop by our office next week and we can discuss it with out team - maybe a few beers and we can see how Mollie can help bring this to fruition.
@willemstuursma Great idea. However, I am on honeymoon leave from Tuesday. So, it will have to wait until November.
Oh congrats! Well, send me an email when you're back and enjoy your honeymoon together!
@frederikbosch congrats! Let's talk about this later!
Hi all. Not sure where to see if there is any activity on this (and the other release) items? Looking for a Money library around which to wrap a series of financial calculators and models - this one works well, bar the precision aspects. I'd have thought the quickest (perhaps not the most elegant) way to get there would have been to allow for instance-specific registration of a calculator (since the calculators can already be created with higher precision) and then to expose a NO_ROUNDING mode on the multiply and divide methods. I see @frederikbosch comments above - I'd probably have gone the other way and expand the functionality of Money, rather than add PreciseMoney to the mix, but I think I can see his motivation. Either way, great library, great potential, so hoping these items are on the cards for the near future!
@pcbulldozer in the mean time, you can also create high precision currencies and use those.
thanks @willemstuursma will be giving this some thought today! appreciate the response.
@willemstuursma Did you take a look and mind sharing your solution?
Just checking in on this thread. I would love to see this PR come to fruition. Not sure what the current status on this is? Did you guys ( @frederikbosch and @willemstuursma ) come to a solution/agreement on how to implement this? Is there something I could do to help? I see there are currently conflicts, but not sure if this idea is abandoned.
So, what do other do with high fraction 8+ numbers?