Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122789
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\))
Subject: Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
In-Reply-To: <62e27e46-f911-5a71-6527-8bba21bf0964@php.net>
Date: Thu, 28 Mar 2024 22:30:15 +0900
Cc: php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <48803EBD-33BB-4433-B125-448759A81868@sakiot.com>
References: <4F094EDA-5058-407D-AF39-06FD934FDE1F@sakiot.com>
 <bbcff629-4dd6-bc50-ac9f-641849dc218a@php.net>
 <68CF373E-6ABF-4471-8992-813B4BA1B508@sakiot.com>
 <62e27e46-f911-5a71-6527-8bba21bf0964@php.net>
To: Derick Rethans <derick@php.net>
From: saki@sakiot.com (Saki Takamachi)

Hi Derick,

>> What is the main difference between getting a read-only property with=20=

>> `->value` and getting the value using a method?
>=20
> Feeling :-) Do we have precedence with other extension's objects=20
> 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`=E2=80=A6.


>> `bcfloor` and `bcceil` originally have no scale specification. This =
is=20
>> because the result is always a string representing an integer value.=20=

>> And since the supported round-mode is the same as standard-round,=20
>> `ROUND_FLOOR` and `ROUND_CEILING` are also supported. Therefore, if=20=

>> want to obtain floor or ceil behavior with a specified scale, I=20
>> recommend specifying the mode as round.
>=20
> 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=20
>>> the example?):
>>>=20
>>> <?php
>>> $num =3D new BcNum('1.23', 2);
>>> $result =3D $num + '1.23456';
>>> $result->value; // '2.46456'
>>> $result->scale; // ??
>>=20
>> In this case, `$result->scale` will be `'5'`. I added this to the =
RFC.
>=20
> Great.=20

This has also been changed to reflect discussion, with slightly =
different results.
```
$num =3D new BcNum('1.23', 2);
$result =3D $num + '1.23456';
$result->value; // '2.46'
$result->scale; // 2
```

> It's what we did for the Date extension, and the Random extension, but=20=

> in this case, it's probably not needed as you say.

> For that, yes. ValueErrors should be distinct from DivideByZeroError =
=E2=80=94 I=20
> think we do have both of those already:
>=20
> php -r 'echo 8/0;'
>=20
> Fatal error: Uncaught DivisionByZeroError: Division by zero in Command=20=

> line code on line 1
>=20
> =46rom the docs for ValueError:
>=20
> "A ValueError is thrown when the type of an argument is correct but =
the=20
> value of it is incorrect."
>=20
> =46rom the docs for DivisionByZeroError:
>=20
> " DivisionByZeroError is thrown when an attempt is made to divide a=20
> number by zero. "
>=20
> 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?=E2=80=9D I couldn't write =
it well in English.

Regards.

Saki=