Re: [RFC] [Discussion] Support object type in BCMath

Hi Tim, Barney, > Your Money example would allow for unsound and/or non-sense > behavior, such as: > > $fiveEuros = new Money(5, 'EUR'); > $tenDollars = new Money(10, 'EUR'); > > $what = $fiveEuros + $tenDollars; > > What would you expect to be in $what? A BcMath\Number(15)? > > ---------------- > > The BcMath\Number class *should* absolutely be final, as a number is a number is a number. > Allowing extension just to be able to write $number->isPrime() instead of isPrime($number) will > allow for very confusing code, such as the example above, with no way to work around it in userland. > It also makes interoperability between two different libraries that expect their own extensions to > work very painful. > > Consider the following example: > > class PrimalityTestingNumber extends Number { > public function isPrime(): bool { } > } > > class ParityTestingNumber extends Number { > public function isEven(): bool { } > public function isOdd(): bool { } > } > > If I now want to create a function to check whether a number is an even prime, I need to do > something like this: > > function isEvenPrime(Number $n) { > return (new PrimalityTestingNumber($n))->isPrime() && (new > ParityTestingNumber($n))->isEven(); > } > > This use case would be much better solved in a generic way using something like this > "Extension Methods" proposal: > https://externals.io/message/118395#118395 > I've already sent a sibling email, explaining why I believe that making the Number class > not final is a mistake. However I'd also like to comment on that specific bit of your email: > > I strongly believe in misuse-resistant APIs. Users should generally be steered towards making > the right choice, even without needing to consult the documentation. For example, by making the > "right choice" the easiest choice or by preventing "wrong choices" entirely. > > Preventing folks from making wrong choices is overall less costly than them realizing that they > made a wrong choice and then being unable to change it, due to backwards compatibility or > interoperability concerns. > > PHP has enough gotchas as it is, so for any new API making it a *great* API, not just an *okay* > API should be part of the consideration. APIs within PHP need to survive for 10+ years. Thanks for that very important point, Tim. I was designing classes with GMP in mind, so I overlooked the point you mentioned. For reference, classes that inherit from GMP return GMP. > Uninitialized is miles better than 0 I think. 0 is a meaningful number just like any other and > we should very strictly avoid inserting made up numbers into people's applications. Let them > fail fast, not output fake data. I'd rather my web shop crashes than gives things away for > free. > Tim has convinced me that it should be a final class, in which case there's no meaningful > distinction between a readonly class and a class with no mutable properties. In that case just for > simplicity I'd say it should be a readonly class. > > > If it's not a final class I think I'm not the right person to ask, since as I said I > don't really like the fact that a readonly class behaves any differently to a class with no > mutable properties. I prefer the behavior of the latter. > Due to the points Tim mentioned, I decided to make BCMath\Number a final class. And, as you say, for clarity's sake I would make it a read-only class. This also means that we don't have to worry about errors due to values ​​not being set in the constructor. Regards. Saki