Hi Gina, > Apologies for the delay, to much traffic on the list so I forgot to address > this.
Don’t worry! > >>> - 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. > > >>> - 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. > > >>> - 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. OK, thanks! >>> - 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 First of all, am I correct in understanding that there is no problem with the naming of "powmod”? Also, given that I have implemented only one "compare()" method, how could this conflict with them? Number is a final class, so there is no room for the user to change its behavior. >>> - 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. That makes sense. However, I would like to have a separate vote on GMP changes. For procedural efficiency, we will combine them into one RFC, but each will be voted on separately, and each requires a 2/3 or more vote in favor. In other words, two primary votes will be held at the same time. Regards, Saki
