What is pros/cons in comparison with moneyphp/money
Insolita opened this issue ยท 9 comments
What is pros/cons in comparison with https://github.com/moneyphp/money ?
+1
+1
We started with moneyphp and we switched to brick/money, as, in my opinion, the design of brick/money is more flexible.
We use money without currency (Users can define a Project-wide currency, and then use this currency throughout the Project). So, actually currency is only handled when we show data to the User. But for a lot of calculations, storing in DB, etc, we still need to work with arbitrary numbers, and brick/money basing on brick/math makes this so easy.
Here is a non-exhaustive list of differences I compiled. I might be wrong about some of the points, if so please feel free to correct me, and I'll update this post.
- it looks like moneyphp does not handle custom scales
- it looks like moneyphp does not handle cash roundings
- brick/money is based on brick/math, which brings multiple advantages:
- it can work on large numbers even when GMP and BCMath are not available - moneyphp will fail in this case, if you exceed the size of a native (32 bit or 64 bit) integer
- calling a Money's
getAmount()
method will return a decimal amount as aBigDecimal
, which lets you harness the full power of brick/math for advanced calculations - moneyphp returns the amount as as string representing the number of cents - factory methods
of()
,ofMinor()
etc. accept all the formats supported by brick/math - moneyphp's is a bit more restrictive - complex calculations can be chained without rounding: see RationalMoney
- moneyphp is a bit verbose when you need to construct a
Money
from a decimal string:while brick/money is a bit more concise:$currencies = new ISOCurrencies(); $moneyParser = new DecimalMoneyParser($currencies); $money = $moneyParser->parse('1000', 'USD');
$money = Money::of('1000', 'USD');
- moneyphp will transparently round amounts, without letting you know:
while brick/money will throw an exception if the given number does not fit in the money's scale:
echo $moneyParser->parse('1.228', 'USD')->getAmount(); // 123 echo Money::EUR('123')->divide(2)->getAmount(); // 62
brick/money will never discard digits, and will always force you to handle rounding where necessary.Money::of('1.228', 'USD'); // RoundingNecessaryException echo Money::of('1.228', 'USD', new CustomContext(4)); // USD 1.2280 echo Money::of('1.228', 'USD', roundingMode: RoundingMode::UP); // USD 1.23 Money::of('1.23', 'EUR')->dividedBy(2); // RoundingNecessaryException echo Money::of('1.23', 'EUR')->dividedBy(2, RoundingMode::UP); // EUR 0.63
- brick/money uses verbs that imply immutability, such as
minus()
vssubtract()
OTOH, moneyphp supports the following features that brick/money doesn't:
Great summary @BenMorel. I'm considering moving my compound prices library to brick/money
. Thank you!
Compare to my project https://github.com/phpexpertsinc/MoneyType. It looks extremely similar.
https://github.com/brick/math/blob/master/src/Internal/Calculator/BcMathCalculator.php
vs
https://github.com/phpexpertsinc/MoneyType/blob/master/src/Internal/BCMathCalcStrategy.php
It's almost 1:1, including your using "Internal" direcotry and strategy pattern.
The MAJOR difference is that my project's only responsibilities are math manipulation and retrieval of currencies to X decimal places, while you'rs does a lot more of currency conversion, multiple currencies, etc.
@BenMorel I think you should add your comment to the readme since this will be a very common question and I personally didn't even think to look in the issues for the answer and only found this after being directed here.
@hopeseekr Thanks for the link, it's always interesting to see how others solve the same problem! I think the major difference between MoneyType and brick/money is that brick/money will by default have a scale that's per-currency (2 for EUR, USD etc.) and complain if you attempt to perform calculations that result in more decimal digits than configured (but provides Contexts to customize this, and RationalMoney to never round); this was a big requirement when creating this library, to ensure that you always handle rounding where necessary, or get an exception.
@iaicam The primary aim of this library is not to be a competitor to moneyphp, so I won't make a paragraph there highlighting the differences. However, you're right that this is becoming a frequently asked question, so I will probably add a link to this issue, and try to keep it up to date! ๐