What is pros/cons in comparison with moneyphp/money

[Insolita]

What is pros/cons in comparison with https://github.com/moneyphp/money ?

[IP-Developer]

+1

[toonvandenbos]

+1

[kohlerdominik]

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.

[BenMorel]

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:

• parsing a string with intl, such as $1.00
• dividing a Money by a Money with ratioOf()

[toonvandenbos]

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

[hopeseekr]

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]

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

[BenMorel]

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