On Tuesday, 25 June 2024 at 17:58, Saki Takamachi <s...@sakiot.com> wrote:
> Hi! > > This is a reminder as the feature freeze is approaching. I would like to > restate my current opinion. Apologies for the delay, to much traffic on the list so I forgot to address this. > > > - Suggestions for using 64-bit integer types internally for performance > > > This is probably unnecessary. It's already fast enough, so it might be a good > idea to consider it when we need even more speed. Also, if we want to speed > things up even more, it would probably be better to change the design of the > bc_num structure. ACK, this seems to be fine. > > > - Points out regarding naming, such as changing "powmod" to “powMod” > > > A function called "divmod" is also commonly used in other languages. If > follow that naming, "powmod" is not unnatural. Since "bcpowmod" already > exists, I feel that it is okay to leave it as "powmod”. > > > - Points out regarding comparison methods > > > For now, all comparisons are possible with just "compare", so I'll use only > one comparison method. This requires an override RFC. I'm grouping those points together. My main concern with adding those methods to the class is that this will potentially conflict with any implementation of operator and/or comparison overloading. This is why I would rather not have the methods at all, if the idea is to have a "procedural" API I feel revisiting Andrea's old "Operator functions" RFC would be better. https://wiki.php.net/rfc/operator_functions > > > - Whether existing BCMath functions should accept BCMath\Number > > > At least not in 8.4. I don't think any ideas for how to use scale properly > will be finalized before the feature freezes. ACK, the context is also different than for ext/gmp which I misremembered. > > > - About the behavior when casting BCMath\Number to bool > > > If the value is 0, it is treated as false, otherwise it is treated as true. > This alone may not require an RFC, but I'm planning to create an RFC for the > comparison method, so I'll include it there. I think this is the most sensible, in which case I think GMP should also follow suit and have the same semantics instead of currently being broken when you try to cast to bool. > > > - Regarding whether the method you plan to publish is really necessary > > I decide to delete the format method. We can cast or get the value from the > property. In some cases, we may consider adding it again, but at least not in > 8.4. This also requires an RFC. > Seems sensible to me. Best regards, Gina P. Banyard
