Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122998
Feedback-ID: id5114917:Fastmail
Content-Type: multipart/alternative;
 boundary="------------VcJX031u40gGhR0xverXtevV"
Message-ID: <b232c9f1-aad9-4ef3-8f23-d0cb2deb0baf@rwec.co.uk>
Date: Sat, 6 Apr 2024 14:43:43 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
To: internals@lists.php.net
References: <D1E3EBAD-A991-4591-B7DE-CF414593E64B@sakiot.com>
 <FB449C0E-1D83-476F-889D-19A6ABDBD38E@sakiot.com>
 <FF0FFBCE-7F03-44A2-B7AE-D3F958135ACB@sakiot.com>
Content-Language: en-GB
In-Reply-To: <FF0FFBCE-7F03-44A2-B7AE-D3F958135ACB@sakiot.com>
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")

This is a multi-part message in MIME format.
--------------VcJX031u40gGhR0xverXtevV
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

On 06/04/2024 07:24, Saki Takamachi wrote:
> 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.


While this is an intriguing idea, it only solves a narrow set of use 
cases. For instance:

- The class might want different behaviour for different operations; 
e.g. Money(42, 'USD') + Money(42, 'USD') should give Money(84, 'USD'); 
but Money(42, 'USD') * Money(42, 'USD') should be an error.

- Properties might need to interact with each other; e.g. Distance(2, 
'metres') + Distance(2, 'feet') could result in Distance(2.6096, 
'metres'); but if you calculate one property at a time, you'll end up 
with Distance(4, 'metres'), which is clearly wrong.

The fundamental problem is that it ignores the OOP concept of 
encapsulation: how an object stores its internal state should not define 
its behaviour. Instead, the object should be able to directly define 
behaviour for the operations it supports.

Regards,

-- 
Rowan Tommins
[IMSoP]

--------------VcJX031u40gGhR0xverXtevV
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 06/04/2024 07:24, Saki Takamachi
      wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:FF0FFBCE-7F03-44A2-B7AE-D3F958135ACB@sakiot.com">
      <pre>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.</pre>
    </blockquote>
    <p><br>
    </p>
    <p>While this is an intriguing idea, it only solves a narrow set of
      use cases. For instance:<br>
    </p>
    <p>- The class might want different behaviour for different
      operations; e.g. Money(42, 'USD') + Money(42, 'USD') should give
      Money(84, 'USD'); but Money(42, 'USD') * Money(42, 'USD') should
      be an error.</p>
    <p>- Properties might need to interact with each other; e.g.
      Distance(2, 'metres') + Distance(2, 'feet') could result in
      Distance(2.6096, 'metres'); but if you calculate one property at a
      time, you'll end up with Distance(4, 'metres'), which is clearly
      wrong.</p>
    <p>The fundamental problem is that it ignores the OOP concept of
      encapsulation: how an object stores its internal state should not
      define its behaviour. Instead, the object should be able to
      directly define behaviour for the operations it supports.<br>
    </p>
    <p>Regards,<br>
    </p>
    <pre class="moz-signature" cols="72">-- 
Rowan Tommins
[IMSoP]</pre>
  </body>
</html>

--------------VcJX031u40gGhR0xverXtevV--