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

Hi Derick, >> What is the main difference between getting a read-only property with >> ->value and getting the value using a method? > > Feeling :-) Do we have precedence with other extension's objects > perhaps already? It depends on the extension. Probably some readonly properties exist in mysqli for example. (However, those in mysqli are only readonly internally, and stubs are not readonly. Therefore, many IDEs do not display errors, so w e don't realize we've written incorrect code until runtime.) The Readonly property was implemented since PHP 8.1, so inner classes implemented before then did not have the option of using the readonly property. As far as I know, no new inner classes with readonly properties or simple getters have been added since PHP 8.1. Therefore, there is currently no precedent that can be compared on the same terms as BCMath\Number…. >> bcfloor and bcceil >> originally have no scale specification. This is >> because the result is always a string representing an integer value. >> And since the supported round-mode is the same as standard-round, >> ROUND_FLOOR and >> ROUND_CEILING are also supported. Therefore, if >> want to obtain floor or ceil behavior with a specified scale, I >> recommend specifying the mode as round. > > OK. That makes sense. Note that we have removed $scale from the calculation method arguments, reflecting the discussion on the mailing list :) >>> - In this example, what would $result->scale show? (Perhaps add that to >>> the example?): >>> >>> <?php >>> $num = new BcNum('1.23', 2); >>> $result = $num + '1.23456'; >>> $result->value; // '2.46456' >>> $result->scale; // ?? >> >> In this case, $result->scale will be >> '5'. I added this to the RFC. > > Great. This has also been changed to reflect discussion, with slightly different results. ``` $num = new BcNum('1.23', 2); $result = $num + '1.23456'; $result->value; // '2.46' $result->scale; // 2 ``` > It's what we did for the Date extension, and the Random extension, but > in this case, it's probably not needed as you say. > For that, yes. ValueErrors should be distinct from DivideByZeroError — I > think we do have both of those already: > > php -r 'echo 8/0;' > > Fatal error: Uncaught DivisionByZeroError: Division by zero in Command > line code on line 1 > > From the docs for ValueError: > > "A ValueError is thrown when the type of an argument is correct but the > value of it is incorrect." > > From the docs for DivisionByZeroError: > > " DivisionByZeroError is thrown when an attempt is made to divide a > number by zero. " > > Subclassing these for BCMath objects seems unnecessary therefore. Thanks. Sorry, I meant "If I create dedicated exception classes, do I need separate classes for each type of error?” I couldn't write it well in English. Regards. Saki