Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

What is pros/cons in comparison with moneyphp/money #28

Insolita opened this issue Jul 23, 2020 · 9 comments

What is pros/cons in comparison with moneyphp/money #28

Insolita opened this issue Jul 23, 2020 · 9 comments


Copy link

Insolita commented Jul 23, 2020

What is pros/cons in comparison with ?

Copy link

IP-Developer commented Jul 26, 2020


1 similar comment
Copy link

toonvandenbos commented Aug 10, 2020


Copy link

kohlerdominik commented Aug 18, 2020

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.

Copy link

BenMorel commented Aug 22, 2020

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 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 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:
    $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.
  • brick/money uses verbs that imply immutability, such as minus() vs subtract()

OTOH, moneyphp supports the following features that brick/money doesn't:

@BenMorel BenMorel pinned this issue Aug 22, 2020
Copy link

toonvandenbos commented Aug 24, 2020

Great summary @BenMorel. I'm considering moving my compound prices library to brick/money. Thank you!

Copy link

hopeseekr commented Aug 25, 2020

Compare to my project It looks extremely similar.

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.

Copy link

that-guy-iain commented Aug 25, 2020

@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.

Copy link

BenMorel commented Aug 25, 2020

@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! 👍

Copy link

BenMorel commented Sep 7, 2020

A link to this issue has been added to the README.

@BenMorel BenMorel closed this as completed Sep 7, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
None yet

No branches or pull requests

7 participants