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

> 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 ​​are 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