[rfc] Immutable variant

[stefanotorresi]

I've been struggling with mutability when using this library, IMHO it has the same issues as \DateTime, and it would greatly benefit from an immutable variant.

Basically, I would like to do the following:

$foo = new BigNumberImmutable(2);
$bar = $foo->multiply(2);

assert($foo == '2');
assert($bar == '4');
assert($bar !== $foo); 

I have seen that there were moontoast#1 and moontoast#2 opened in the old repo, but it has been pretty much abandoned so I'd like to pick this up.
With that proposal, I didn't particularly like the introduction of a constructor parameter in the parent and a child class, so I would follow a different approach.

While I get started, I'd like your feedback, because I'm considering two options:

1. BC Safe

Follow exactly the same approach that was implemented for \DateTime:

• Introduce a new BigNumberInterface.
• Make BigNumber implement it.
• Introduce a new class BigNumberImmutable, also implementing BigNumberInterface.

This could target a minor 1.x release, I guess 1.2.

2. Non BC Safe

• Rename BigNumber to BigNumberMutable.
• Extract a new interface BigNumber from it, and make it implement it.
• Introduce a new class BigNumberImmutable, also implementing BigNumber.

Over approach 1, this would have the arguable benefit of better expressing the type hierarchy, but I realise that this is more a stylistic choice than anything else, and I don't want to start any religion war on the *Interface suffix.
The downside of this approach is that it would of course have to target a major release, I guess 2.0, because BigNumber would be no longer "newable".
That said, migrating to the new version would only require a use alias statement.

[ramsey]

I agree that there should be an immutable form of BigNumber. Unfortunately, I'm considering abandoning this library in favor of something else (either written by myself or someone else). I wouldn't like to see you invest a lot of time into something I'm abandoning. 😄

See also ramsey/uuid#109 and ramsey/math. The ramsey/math package is only stubbed out based on some ideas I had over a year ago. I haven't done anything else with it, and I'm open to recommending a third-party (not written by me) library as an alternative to moontoast/math.

Thoughts?

[stefanotorresi]

@ramsey I see where you're coming from about maintaining someone else's library.

That said, ramsey/math intentions look a bit broader in scope than just arbitrary precision numbers and, as much as I'm willing to help, I'm not a math guru.

I'll do what I can if you're willing to undertake the commitment.

I don't have any third-party recommendations: apart from moontoast/math being the most downloaded bcmath wrapper in the wild, I've looked at others and didn't find them particularly more compelling, plus honestly I choose this library also because I appreciated your involvement with it.

I will say this much, though:

zendframework/zend-math is solid but, apart also requiring mb_string, it doesn't provide a value object implementation (which is what I'm looking for), just a set of static methods.

litipk/php-bignumbers is the closest alternative, but I find the api somewhat less intuitive.

Any other math lib I've seen is either bloated or uses the static method approach, which I don't really like.

I'll go as far as this: tonight I'll wrap up a PR with a BC-safe immutable implementation here. You then decide whether to merge it or not, but for the time being I will at least have the VO I'm in dire need of.

Then, we can see if and how we can work together to deprecate this lib entirely.