Closed Insolita closed 4 years ago
+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.
getAmount()
method will return a decimal amount as a BigDecimal
, which lets you harness the full power of brick/math for advanced calculations - moneyphp returns the amount as as string representing the number of centsof()
, ofMinor()
etc. accept all the formats supported by brick/math - moneyphp's is a bit more restrictiveMoney
from a decimal string:
$currencies = new ISOCurrencies();
$moneyParser = new DecimalMoneyParser($currencies);
$money = $moneyParser->parse('1000', 'USD');
while brick/money is a bit more concise:
$money = Money::of('1000', 'USD');
moneyphp will transparently round amounts, without letting you know:
echo $moneyParser->parse('1.228', 'USD')->getAmount(); // 123
echo Money::EUR('123')->divide(2)->getAmount(); // 62
while brick/money will throw an exception if the given number does not fit in the money's scale:
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 will never discard digits, and will always force you to handle rounding where necessary.
minus()
vs subtract()
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! 👍
What is pros/cons in comparison with https://github.com/moneyphp/money ?