Money's internal amount should be a string

[frederikbosch]

Fixes #133.

[frederikbosch]

In order to create a MoneyParser PR, I need this to be merged. I just improved more docblock and squashed my commit.

[sagikazarmark]

Do we really need a separate method for that?

[frederikbosch]

No, we really do not need it. Removed it, and squashed again.

[sagikazarmark]

I would say we need that space after the comma.

[sagikazarmark]

Well, I tend accept this merge, but still need to get used to the fact that amount will be stored as string.

[frederikbosch]

@sagikazarmark I agree. It is a big change. #115 was more comprehensive than I thought at first.

[sagikazarmark]

Merging the deprecation PR caused some conflicts.

[frederikbosch]

Yeah, and now I need to rebase? :) Still don't know how, sorry about that...

[sagikazarmark]

No problem, I will do it.

[sagikazarmark]

Conflicts solved in #136

[josecelano]

Some months ago I was testing how to deal with bit integers and I did this fork:

https://github.com/josecelano/money/blob/master/lib/Money/BigMoney.php

Instead of using integer or string for the amount I used another class. In this implementation Money has not the responsibility to deal with bit integers and it delegates to another class. The only problem is that library uses only bcmath extension. But maybe there is another similar class which uses calculatorsas you did it.

[frederikbosch]

@josecelano bcmath is the only option for PreciseMoney. I rather use that term than BigMoney, because we already have BigMoney because there is no more integer limit. GMP only uses integers, not decimals, see the RFC for floating points integration in PHP.

The solution I will propose soon will have the following structure.

• PreciseCalculator with methods like roundPrecisely
• PreciseMoney
• BcMathCalculator implementing PreciseCalculator
• I still have to think have to deal with formatting and parsing.

When the RFC for GMP lands, we only have to implement PreciseCalculator for GMP.

[josecelano]

Sorry,there was definitely a misunderstanding. What I called BigMoney is an implementation of Money which allows big integers, not decimals. I used Decimal class but internally I force the constrain of not using decimals, I mean all values would have no deciaml part even if that class allows it. But the idea I want to expose is you could use another class to store the amount and delegate to that class the responsabiliti of dealing with bit integers. In fact, I was looking for a BigInteger class but I do nto remember why finally I decided to use Decimal for that test.

[sagikazarmark]

Yeah, BigMoney casued a lot of confusion in me as well. But it refers to the precision of the value, not the integer size.