Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123274
Message-ID: <93bb5d8b-431b-4e89-acda-64d8ebe5bbe6@bastelstu.be>
Date: Tue, 7 May 2024 20:24:16 +0200
Precedence: bulk
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] [vote] Support object type in BCMath
To: "Gina P. Banyard" <internals@gpb.moe>, Saki Takamachi <saki@sakiot.com>
Cc: php internals <internals@lists.php.net>
References: <58283467-CABC-4868-A691-A52228C5296F@sakiot.com>
 <6Kx-yDO_RoWi8qV0NDhpziE5VX-cDF3g5RCEUjqh5iOnM2x2pWtYPz0j3bNUz-BdkkIVXXG38tu8fP9FuAiQYl2oDcTYAUivNn63B10Vw9I=@gpb.moe>
 <9BD04F6A-95FA-4C04-AE9C-B9ACB92A9D58@sakiot.com>
 <pjiOa-Rruk4s7NZVa_1doLG_UYGly0A_J2VPfjU-AhddTI_6XQ6m1Ih5oSMYOaEZp73i4MvfCmcg0N2P1IWcthfzSXgEifhDxL29eCQdxC0=@gpb.moe>
Content-Language: en-US
In-Reply-To: <pjiOa-Rruk4s7NZVa_1doLG_UYGly0A_J2VPfjU-AhddTI_6XQ6m1Ih5oSMYOaEZp73i4MvfCmcg0N2P1IWcthfzSXgEifhDxL29eCQdxC0=@gpb.moe>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

On 5/7/24 17:23, Gina P. Banyard wrote:
>>> - What is the behaviour when casting a Number object to bool? Does it always cast to true like a "standard" object, or does a Number equal to 0 cast to false?
>>
>>
>> That's a good topic. I didn't include any mention of this in the RFC because there was no discussion about it. Personally, I like to return a bool value that reflects the internal numerical state, like an int.
>>
>> However, since I would like to avoid adding such specifications later when voting has already begun, I will use the same as a "standard object" for now. If this RFC is passed, I will additionally propose it in another RFC.
> 
> The lack of discussion about this topic is not a good excuse for not having addressed this in the RFC.
> This topic should have come up on its own while writing the RFC as this is something that you should have considered, in the same way you have considered how casting to string works.
> Moreover, RFC discussions are steered by the content of the RFC, and non-mentioned issues requires other people to consider cases that have not been explicitly address, something that is difficult.
> 
> 
> I feel this RFC has been brought to a vote too early, as such I am changing my vote to no.
> I am generally in favour of the concept, but there are too many details that are unanswered or didn't even get proper attention for me to feel comfortable with the state of the RFC in question.

Thank you for spelling out the feelings that I had towards the RFC but 
wasn't able to clearly put into words myself.

Unfortunately I had not seen the announcement about the vote in time, 
and wasn't able to give the RFC a final read before the vote. Personally 
I also didn't expect a vote yet, because I felt the API surface of the 
new class hasn't yet been given a proper thought and discussion, 
including all possible edge cases. Most of the discussion I remember 
revolved around final vs not-final and how to correctly perform the 
rounding / expansion of scale (the latter of which I couldn't comment 
on, as numeric programming is not my area of expertise), not the API 
surface / the methods that are exposed. As an example, my concern about 
the `format()` method has been left unresolved.

As such, I'm also voting "no", because I feel like the exposed API is 
worse than it could be, but I also support the concept in principle.

Best regards
Tim Düsterhus