On Wednesday, 1 May 2024 at 09:55, Saki Takamachi <s...@sakiot.com> wrote:
> Hi all! > > Voting for RFC: Support object type in BCMath has started. Voting ends on > 2024-05-16 00:00 GMT. > https://wiki.php.net/rfc/support_object_type_in_bcmath > > Regards, > > Saki I voted in favour, as Number being its own type should improve DX and performance for small numbers as we can just store two 64bit integer, one for the integral and another for the fractional part. However, I have some remarks and questions. Apologies if these were already brought up, but I haven't gone through the whole 100 long email thread. - The comparison method should either be called "cmp", or "compare" to align with other extensions, the BC Math function being called bc_comp is weird. - I don't understand why we are exposing lt, lte, gt, and gte what is the rationale here? Also, the naming is kinda terrible IMHO. - The "powmod" method should probably be called "powMod" - Are the existing BCMath function going to be adapted to handle the new Number object or not? - 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? - Considering the property hook RFC has been accepted, should the $value property be a "virtual" property or not? Best regards, Gina P. Banyard
