Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122953
Precedence: bulk
MIME-Version: 1.0
References: <4F094EDA-5058-407D-AF39-06FD934FDE1F@sakiot.com>
 <bbcff629-4dd6-bc50-ac9f-641849dc218a@php.net> <68CF373E-6ABF-4471-8992-813B4BA1B508@sakiot.com>
 <904197f4-afb5-401e-9e17-7a655c5449d0@alec.pl> <CAMrTa2EK6ymBQuxeFj7tMV0M2crqCCCR=mLN-FSfuCgrQHEZ6A@mail.gmail.com>
 <AB663F3F-A888-45F7-B19A-00530A4EDB0C@sakiot.com> <CAMrTa2HOEUWQcPdZE3FZ9JWCS1DWuRTNhhfqGGZOmr=v1Mctdw@mail.gmail.com>
 <CANS-=pfVuKKfAiu0LUJTrEPnSRaa_nHwJCgMvSORruAwHMsvQg@mail.gmail.com>
 <CAMrTa2HXD+62TKbaaA-v-mct5zdR5ortUAbtG1R1D22amAgpNA@mail.gmail.com>
 <CAMrTa2GaK3AUp0WodhNO8RdvoLbbiCk14Gs2oWF6vEs_+qMYNg@mail.gmail.com>
 <655FEA80-9AB4-4AAD-A310-70ED968C97A2@sakiot.com> <CAMrTa2Fh_-M_Kezi7s_4P4+a+dTyKq=RExd6ARPRDqZYS175kA@mail.gmail.com>
 <CAMrTa2FrkvNPK6kETNJFNNDn0mL5dxkV=PmdxsysruhhjY=Uig@mail.gmail.com>
 <8FB87901-02D7-4934-9119-55B21CEDDA9D@sakiot.com> <CAMrTa2EJf2NK2D3J=q7xkAVuNKsjEBDVv+RDmxp_g9DSsjRgwg@mail.gmail.com>
 <65e0fc8b-ed4e-4bf8-af2d-77dc7b4bb934@redmagic.org.uk>
In-Reply-To: <65e0fc8b-ed4e-4bf8-af2d-77dc7b4bb934@redmagic.org.uk>
Date: Thu, 4 Apr 2024 15:36:54 -0700
Message-ID: <CAMrTa2GsydsTtorY9hcEcjDZe2Uu+mRo8Wz9+0Dedc4OCdLtUg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Support object type in BCMath
To: Barney Laurance <barney@redmagic.org.uk>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="000000000000d2ff9c06154cfaee"
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--000000000000d2ff9c06154cfaee
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 4, 2024 at 2:19=E2=80=AFPM Barney Laurance <barney@redmagic.org=
.uk>
wrote:

>
> I don't think it will be possible to make a good Money class as a child o=
f
> this. BcNum is a read-only class, so if the constructor of BcNum is final
> then the child class won't be able to take the currency as a constructor
> param, and won't be able to protect the invariant that currency must be
> initialized. If the constructor of BcNum were made non-final then BcNum
> wouldn't be able to protect the invariant of the numeric value always bei=
ng
> initialized once the constructor has returned. And it should be
> straightforward to make a good money class as a composition of BcNum and =
a
> currency enum or string.
>
> The RFC does not list the constructor as final, and I would not expect it
to.

> There's probably not any good use case for a subclass to add properties,
> unless perhaps the subclass developers are willing do do away with some o=
f
> the checks that would normally be done on a value object by the PHP runti=
me
> to keep it valid (maybe replacing them with static analysis checks). But
> there are lots of reasonable use cases for subclasses to add methods, eve=
n
> if they're effectively syntax sugar for static methods with a BcNum typed
> param.
>
> I literally just provided in the quote you are replying to a good use cas=
e
for a subclass. You can do the same thing with composition yeah, and that
might even be better to a lot of people, but I don't think this RFC should
take a position AGAINST subclasses and in favor of composition.

> Having just written that I've now checked the behavior of DateTime - see
> https://3v4l.org/5DQZg . The constructor of that isn't final, so a child
> class can replace it with an empty constructor. But if it does that and
> leaves the value uninitialized then it blows up on a call to `format`.
> That's probably not something we should emulate. DateTimeImmutable behave=
s
> the same way.
>
Why not? Writing something like that obviously does not work, and the error
would be immediately apparent. Is it possible to create something that will
error? Of course. That's not an error that needs to be aggressively guarded
against, because the feedback is rapid and obvious.

Jordan

--000000000000d2ff9c06154cfaee
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 Thu, Apr 4, 2024 at 2:19=E2=80=AFP=
M Barney Laurance &lt;<a href=3D"mailto:barney@redmagic.org.uk">barney@redm=
agic.org.uk</a>&gt; wrote:<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"><br><div><p>I don&#39;t think it will be possible to make a good=
 Money class as a
      child of this. BcNum is a read-only class, so if the constructor
      of BcNum is final then the child class won&#39;t be able to take the
      currency as a constructor param, and won&#39;t be able to protect the
      invariant that currency must be initialized. If the constructor of
      BcNum were made non-final then BcNum wouldn&#39;t be able to protect
      the invariant of the numeric value always being initialized once
      the constructor has returned. And it should be straightforward to
      make a good money class as a composition of BcNum and a currency
      enum or string.<br>
      <br></p></div></blockquote><div>The RFC does not list the constructor=
 as final, and I would not expect it to. <br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,2=
04,204);padding-left:1ex"><div><p>
      There&#39;s probably not any good use case for a subclass to add
      properties, unless perhaps the subclass developers are willing do
      do away with some of the checks that would normally be done on a
      value object by the PHP runtime to keep it valid (maybe replacing
      them with static analysis checks). But there are lots of
      reasonable use cases for subclasses to add methods, even if
      they&#39;re effectively syntax sugar for static methods with a BcNum
      typed param.<br>
      <br></p></div></blockquote><div>I literally just provided in the quot=
e you are replying to a good use case for a subclass. You can do the same t=
hing with composition yeah, and that might even be better to a lot of peopl=
e, but I don&#39;t think this RFC should take a position AGAINST subclasses=
 and in favor of composition. <br></div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pad=
ding-left:1ex"><div><p>
      Having just written that I&#39;ve now checked the behavior of DateTim=
e
      - see <a href=3D"https://3v4l.org/5DQZg" target=3D"_blank">https://3v=
4l.org/5DQZg</a> . The constructor of that isn&#39;t
      final, so a child class can replace it with an empty constructor.
      But if it does that and leaves the value uninitialized then it
      blows up on a call to `format`. That&#39;s probably not something we
      should emulate. DateTimeImmutable behaves the same way.<br></p></div>=
</blockquote><div>Why not? Writing something like that obviously does not w=
ork, and the error would be immediately apparent. Is it possible to create =
something that will error? Of course. That&#39;s not an error that needs to=
 be aggressively guarded against, because the feedback is rapid and obvious=
.</div><div><br></div><div>Jordan <br></div></div></div>

--000000000000d2ff9c06154cfaee--