Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123006
Precedence: bulk
MIME-Version: 1.0
References: <D1E3EBAD-A991-4591-B7DE-CF414593E64B@sakiot.com>
 <FB449C0E-1D83-476F-889D-19A6ABDBD38E@sakiot.com> <FF0FFBCE-7F03-44A2-B7AE-D3F958135ACB@sakiot.com>
 <b232c9f1-aad9-4ef3-8f23-d0cb2deb0baf@rwec.co.uk>
In-Reply-To: <b232c9f1-aad9-4ef3-8f23-d0cb2deb0baf@rwec.co.uk>
Date: Sat, 6 Apr 2024 17:24:48 -0700
Message-ID: <CAMrTa2F181uGoJgZrUx6kwvDj=J1JOAWTqoYQuPoAgNacrfO3g@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000002ac9bd061576b8a7"
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--0000000000002ac9bd061576b8a7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Apr 6, 2024 at 6:45=E2=80=AFAM Rowan Tommins [IMSoP] <imsop.php@rwe=
c.co.uk>
wrote:

> 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.
>
>
If only there had been a feature that carefully considered how all those
things would interact. Oh well.

Okay, then please tell me in which use cases inheritance rather than
> composition is the right choice? For the "Money" example, I've already
> showcased how it would be broken and I can't think of any example where
> inheritance would be superior to composition.
>
> Yes, my example is dumb, but nevertheless it showcased that the native
> and unchangeable operations would be unsound for child classes with
> custom properties, because the operations would not be able to correctly
> fill in the custom properties.
>

No, like I said, I disagree, but I don't get a vote AND it's not something
I would actually vote no over if I could, so it's not something I'm willing
to put the effort into in that way. I was voicing my disagreement to make
sure it was part of the discussion but I wasn't trying to put the effort
into actually changing the design of the RFC, which I understand is a
little unsatisfactory to some.

As it is, this RFC will be useful to some for sure, but my library will
ignore it.

Jordan

--0000000000002ac9bd061576b8a7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Sat, Apr 6, 2024 at 6:45=E2=80=AFA=
M Rowan Tommins [IMSoP] &lt;<a href=3D"mailto:imsop.php@rwec.co.uk">imsop.p=
hp@rwec.co.uk</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi=
ng-left:1ex"><u></u>

 =20
   =20
 =20
  <div>
    <div>On 06/04/2024 07:24, Saki Takamachi
      wrote:<br>
    </div>
    <blockquote type=3D"cite">
      <pre>Take a look at the methods shown below:
```
protected static function resultPropertyRules(string $propertyName,=20
mixed $value1, mixed $value2): mixed {}
```

This method determines which operand value to use in the result after=20
calculation for a property that the user has defined by extending the=20
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, &#39;USD&#39;) + Money(42, &#39;USD&#39;) =
should give
      Money(84, &#39;USD&#39;); but Money(42, &#39;USD&#39;) * Money(42, &#=
39;USD&#39;) should
      be an error.</p>
    <p>- Properties might need to interact with each other; e.g.
      Distance(2, &#39;metres&#39;) + Distance(2, &#39;feet&#39;) could res=
ult in
      Distance(2.6096, &#39;metres&#39;); but if you calculate one property=
 at a
      time, you&#39;ll end up with Distance(4, &#39;metres&#39;), 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><br></div></blockquote><div><br></div><div>If only there had been a=
 feature that carefully considered how all those things would interact. Oh =
well.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"=
>
Okay, then please tell me in which use cases inheritance rather than <br>
composition is the right choice? For the &quot;Money&quot; example, I&#39;v=
e already <br>
showcased how it would be broken and I can&#39;t think of any example where=
 <br>
inheritance would be superior to composition.<br>
<br>
Yes, my example is dumb, but nevertheless it showcased that the native <br>
and unchangeable operations would be unsound for child classes with <br>
custom properties, because the operations would not be able to correctly <b=
r>
fill in the custom properties.=C2=A0 <br></blockquote><div><br></div><div>N=
o, like I said, I disagree, but I don&#39;t get a vote AND it&#39;s not som=
ething I would actually vote no over if I could, so it&#39;s not something =
I&#39;m willing to put the effort into in that way. I was voicing my disagr=
eement to make sure it was part of the discussion but I wasn&#39;t trying t=
o put the effort into actually changing the design of the RFC, which I unde=
rstand is a little unsatisfactory to some.</div><div><br></div><div>As it i=
s, this RFC will be useful to some for sure, but my library will ignore it.=
</div><div><br></div><div>Jordan<br></div></div></div>

--0000000000002ac9bd061576b8a7--