Re: [Discussion] Follow-up RFC for BCMath\Number object

Hi! This is a reminder as the feature freeze is approaching. I would like to restate my current opinion. > - 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. > - 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. > - 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. > - 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. > - 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. Regards, Saki