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
