Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122992
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6.1.1\))
Subject: Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
In-Reply-To: <FB449C0E-1D83-476F-889D-19A6ABDBD38E@sakiot.com>
Date: Sat, 6 Apr 2024 15:24:26 +0900
Cc: =?utf-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>,
 Lynn <kjarli@gmail.com>,
 Aleksander Machniak <alec@alec.pl>,
 php internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <FF0FFBCE-7F03-44A2-B7AE-D3F958135ACB@sakiot.com>
References: <D1E3EBAD-A991-4591-B7DE-CF414593E64B@sakiot.com>
 <FB449C0E-1D83-476F-889D-19A6ABDBD38E@sakiot.com>
To: Jordan LeDoux <jordan.ledoux@gmail.com>
From: saki@sakiot.com (Saki Takamachi)

> I'll try to think of some more good ideas, but if you have any =
suggestions, please let me know.

Regarding `$roundMode`, a possible approach is to clarify the priority =
of the current eight values, and if they are different, apply the one =
with the higher priority.

With that in mind, the question that remains is which of the following =
three elements should I give up on?

1. User freedom (inheritability)
2. Commutativity of computation
3. Simplicity

Giving up on 1 means adopting a final class. Giving up 2 means always =
prefering the left operand to determine the properties of the result. =
(However, I don't really like giving up 2)

In this email, I will explain the approach if you give up on 3. This is =
an approach I just came up with earlier.

Take a look at the methods shown below:
```
protected static function resultPropertyRules(string $propertyName, =
mixed $value1, mixed $value2): mixed {}
```

This method determines which operand value to use in the result after =
calculation for a property that the user has defined by extending the =
class. Calling this in the Number class is pointless and will throw an =
exception. Child classes may not necessarily need to override this.

Here are the details. These examples assume that all calculations are =
performed between objects of classes that inherit from Number. =
Additionally, "properties" in the description refer to properties =
defined by the user.

- Objects to be calculated must be a parent-child relationship or be of =
the same class.
- If they are different objects (parent-child relationship), the =
calculation result will always be the class of the child.
- `resultPropertyRules()` is not called if it is possible to implicitly =
determine which properties the result should have.
- If cannot determine the value of a property that the result should =
have, call `resultPropertyRules()` for that property. In other words, =
`resultPropertyRules()` is called as many times as there are properties =
that need to be evaluated.
- If `resultPropertyRules()` needs to be called and =
`resultPropertyRules()` is not overridden, an exception will be thrown.
- Similarly, if use `resultPropertyRules()` and the value cannot be =
determined properly (for example, if it returns a value of a different =
type), it will also throw an exception.

Supplement: Example when it is possible to determine the value to be =
used implicitly

- If the user has not defined the property
- If all property values =E2=80=8B=E2=80=8Bare exactly the same
- For objects in a parent-child relationship, if a certain property =
exists only on the child side

Points that need discussion

- Suppose that in an object with a parent-child relationship, a certain =
property is defined on the parent side. In that case, which definition =
should be used for `resultPropertyRules()`, parent or child?
- A more specific case of the above question: What if the visibility of =
the property defined in the parent is private?

Regards.

Saki=