Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:122941
Content-Type: multipart/alternative;
 boundary="------------tE60tlqG61W6NA9qjoAsnWNs"
Message-ID: <2c2f2731-acee-4c70-93d9-8ec6d9edc4db@redmagic.org.uk>
Date: Thu, 4 Apr 2024 21:58:24 +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: <4F094EDA-5058-407D-AF39-06FD934FDE1F@sakiot.com>
 <91111e11ee72ffd18e1a1b2412246d00@gliadin.co.uk>
 <94B21565-9129-4379-A720-F4EDDD0A8D84@sakiot.com>
Content-Language: en-US
In-Reply-To: <94B21565-9129-4379-A720-F4EDDD0A8D84@sakiot.com>
From: barney@redmagic.org.uk (Barney Laurance)

This is a multi-part message in MIME format.
--------------tE60tlqG61W6NA9qjoAsnWNs
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hi again,

On 27/03/2024 00:40, Saki Takamachi wrote:
>> Do we also need `toFloat` and `toInt` functions? Seems like using explicit functions will be safer than casting.
>>
>> For toInt I'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 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 proposing too many features will complicate the RFC and make it difficult to get 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` 
or `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.


--------------tE60tlqG61W6NA9qjoAsnWNs
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">Hi again,<br>
      <br>
      On 27/03/2024 00:40, Saki Takamachi wrote:<span
      style="white-space: pre-wrap">
</span></div>
    <blockquote type="cite"
      cite="mid:94B21565-9129-4379-A720-F4EDDD0A8D84@sakiot.com">
      <blockquote type="cite">
        <pre class="moz-quote-pre" wrap="">Do we also need `toFloat` and `toInt` functions? Seems like using explicit functions will be safer than casting.

For toInt I'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 is outside the range of floats or return INF or -INF,
or possibly the user should just check for infinite values themselves.
</pre>
      </blockquote>
      <pre class="moz-quote-pre" wrap="">
I was thinking about those features too. However, I'm concerned that proposing too many features will complicate the RFC and make it difficult 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't have these functions. Casting and calling
      `intval` or `floatval` all feel like slightly awkward workarounds
      that shouldn't be needed in a greenfield project. We know that the
      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>
  </body>
</html>

--------------tE60tlqG61W6NA9qjoAsnWNs--