Re: Native decimal scalar support and object types in BcMath - do we want both?

On 7 April 2024 11:44:22 BST, Saki Takamachi <saki@sakiot.com> wrote: >I don't think the two threads can be combined because they have different goals. If one >side of the argument was, "How about to add BCMath?" then perhaps we should merge the >discussion. But BCMath already exists and the agenda is to add an OOP API. > >In other words, one is about adding new features, and the other is about improving existing >features. While I appreciate that that was the original aim, a lot of the discussion at the moment isn't really about BCMath at all, it's about how to define a fixed-precision number type. For instance, how to specify precision and rounding for operations like division. I haven't seen anywhere in the discussion where the answer was "that's how it already works, and we're not adding new features". Is there anything in the proposal which would actually be different if it was based on a different library, and if not, should we be designing a NumberInterface which multiple extensions could implement? Then Jordan's search for a library with better performance could lead to new extensions implementing that interface, even if they have portability or licensing problems that make them awkward to bundle in core. Finally, there's the separate discussion about making a new "scalar type". As I said in a previous email, I'm not really sure what "scalar" means in this context, so maybe "integrating the type more directly into the language" is a better description? That includes memory/copying optimisation (potentially linked to Ilija's work on data classes), initialisation syntax (which could be a general feature), and accepting the type in existing functions (something frequently requested for custom array-like types). In other words, looking at how the efforts overlap doesn't have to mean abandoning one of them, it can mean finding how one can benefit the other. Regards, Rowan Tommins [IMSoP]