Re: [Discussion] Follow-up RFC for BCMath\Number object
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
Thread (4 messages)