Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122943
Precedence: bulk
MIME-Version: 1.0
References: <4F094EDA-5058-407D-AF39-06FD934FDE1F@sakiot.com>
 <91111e11ee72ffd18e1a1b2412246d00@gliadin.co.uk> <94B21565-9129-4379-A720-F4EDDD0A8D84@sakiot.com>
 <2c2f2731-acee-4c70-93d9-8ec6d9edc4db@redmagic.org.uk>
In-Reply-To: <2c2f2731-acee-4c70-93d9-8ec6d9edc4db@redmagic.org.uk>
Date: Thu, 4 Apr 2024 14:10:08 -0700
Message-ID: <CAMrTa2FKDqFHunW9iN8oYQ7kQDCcNqg0upo6MqRfLikpn4PFuw@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="0000000000007707f606154bc491"
From: jordan.ledoux@gmail.com (Jordan LeDoux)

--0000000000007707f606154bc491
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Thu, Apr 4, 2024 at 1:59=E2=80=AFPM Barney Laurance <barney@redmagic.org=
.uk>
wrote:

> Hi again,
>
> On 27/03/2024 00:40, Saki Takamachi wrote:
>
> Do we also need `toFloat` and `toInt` functions? Seems like using explici=
t functions will be safer than casting.
>
> For toInt I'd expect an exception if the value is outside the range of po=
ssible ints. For toFloat it might be nice to have a flag
> argument to give the developer the choice of having it throw if the value=
 is outside the range of floats or return INF or -INF,
> or possibly the user should just check for infinite values themselves.
>
> I was thinking about those features too. However, I'm concerned that prop=
osing too many features will complicate the RFC and make it difficult to ge=
t it approved.
>
> Coming back to this point, I think these are basic features that people
> would expect to be there - I think I would find just slightly frustrating
> to start learning how to use a class like this and then
> find that it doesn't have these functions. Casting and calling `intval` o=
r
> `floatval` all feel like slightly awkward workarounds that shouldn't be
> needed in a greenfield project. We know that the string
> inside the object is always a numeric string, so it should be easier to
> parse it as an int than to parse it as a date or a JSON document. Code
> doing the latter should stand out as odd looking.
>
>
>
The class cannot guarantee that it can return a value in the type you
request however, so the way that is handled would need to be decided. The
value can easily be outside of the range of an int. Should it return a
float silently in that case for `toInt()`? What if the value is beyond the
range of a float? That would be a very rare situation, as floats can
represent extremely large numbers (with very reduced accuracy), but I would
expect it to throw an exception if that happened. Ideally an exception that
I could catch and ignore, since I can almost surely deal with that error in
most situations.

What about a number that is so small that it can't fit in a float? Similar
situation, though I expect it would occur slightly more often than a number
being too large to fit in a float, even though it would also be rare.

I think these helper functions belong in the RFC, but they aren't quite
straightforward, which is what I think Saki was alluding to.

Jordan

--0000000000007707f606154bc491
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 1:59=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"><u></u>

 =20
   =20
 =20
  <div>
    <div>Hi again,<br>
      <br>
      On 27/03/2024 00:40, Saki Takamachi wrote:<span style=3D"white-space:=
pre-wrap">
</span></div>
    <blockquote type=3D"cite">
      <blockquote type=3D"cite">
        <pre>Do we also need `toFloat` and `toInt` functions? Seems like us=
ing explicit functions will be safer than casting.

For toInt I&#39;d expect an exception if the value is outside the range of =
possible ints. For toFloat it might be nice to have a flag
argument to give the developer the choice of having it throw if the value i=
s outside the range of floats or return INF or -INF,
or possibly the user should just check for infinite values themselves.
</pre>
      </blockquote>
      <pre>I was thinking about those features too. However, I&#39;m concer=
ned that proposing too many features will complicate the RFC and make it di=
fficult to get it approved.
</pre>
    </blockquote>
    <p>Coming back to this point, I think these are basic features that
      people would expect to be there - I think I would find just
      slightly frustrating to start learning how to use a class like
      this and then<br>
      find that it doesn&#39;t have these functions. Casting and calling
      `intval` or `floatval` all feel like slightly awkward workarounds
      that shouldn&#39;t be needed in a greenfield project. We know that th=
e
      string<br>
      inside the object is always a numeric string, so it should be
      easier to parse it as an int than to parse it as a date or a JSON
      document. Code doing the latter should stand out as odd looking.<br>
      <br>
      <br></p></div></blockquote><div><br></div><div>The class cannot guara=
ntee that it can return a value in the type you request however, so the way=
 that is handled would need to be decided. The value can easily be outside =
of the range of an int. Should it return a float silently in that case for =
`toInt()`? What if the value is beyond the range of a float? That would be =
a very rare situation, as floats can represent extremely large numbers (wit=
h very reduced accuracy), but I would expect it to throw an exception if th=
at happened. Ideally an exception that I could catch and ignore, since I ca=
n almost surely deal with that error in most situations.</div><div><br></di=
v><div>What about a number that is so small that it can&#39;t fit in a floa=
t? Similar situation, though I expect it would occur slightly more often th=
an a number being too large to fit in a float, even though it would also be=
 rare.</div><div><br></div><div>I think these helper functions belong in th=
e RFC, but they aren&#39;t quite straightforward, which is what I think Sak=
i was alluding to.</div><div><br></div><div>Jordan<br></div></div></div>

--0000000000007707f606154bc491--