Money equability algorithm

[anikeevda]

I would like to discuss that makes two Money objects - equals. From my point of view, it should be currency (thats quiet obvious, yes), amount (thats obvious too) but that about scale attribute?

Example: 5.0000 RUB and 5.00001000 RUB

So my question is does this two objects equals and in which cases? If we checks their equality with scale 4 they probably equal and they not if we checks with scale 8. And is it correct to allow checking objects for equality with different scales?

[stepanets]

I thought the main issue is hardcoded scale and how it should be handled

[anikeevda]

I thought the main issue is hardcoded scale and how it should be handled

Thats a more complicated issue than just hardcoded scale. Even more after moving hardcoded scale to constructor params this issue will be very actual. Because when scale is hardcoded there are no need to compare.

[stepanets]

We needn't any equals methods in the interface, in the Money context money are equals when equals amount and currency. $5.00 equals $5.0000. Scale can be useful in further operations with money. So we can add scale(): int method in Money interface.

And the second option is to hardcode scale with enough digits e.g. 16. In this case client side will be decide how many digits will used in business logic.

[tigokr]

maybe good decision to create base classes for fiat and electronic money? where fiat with predefined precision and electronic user defined?
in this way we will reduce a bit extra complexity in cases where it not required

[stepanets]

Do you mean some kind of factories like this one?

<?php

class BTC implements Money
{
    public function __construct(string amount)
    {
        $this->origin = new JustMoney($amount, new BTC(), 8);
    }
}

So, do you agree to add scale method in the Money interface?

[stepanets]

I have one more thought - what if the scale belongs to currency?
When we reason about scale we think in currency context e.g. for classic currencies 4 digits is enough and for BTC we need 8 and for SuperBTC it will be 12

[tigokr]

no, if we talk about strong banking every part of only pesos have value, because big amount of this parts is turning into big profit
i think example with billion of debit accounts is not necessary

[stepanets]

so you vote for scale(): int method in money interface?

[anikeevda]

so you vote for scale(): int method in money interface?

scale or precision maybe

[stepanets]

scale is more laconic

[anikeevda]

scale is more laconic

possibly

But Im still think scale is an object of another issue which implementation could help us solve current. Because Im sure we need some Equals class which must include scale in equality calculation.

[tigokr]

what if precision(): Precision? that hides this complexity and which you can configure in equity requirements

[anikeevda]

I think we could close this 'cause all discussied functionality were implemented in #7