Re: Proposal: native decimal scalar type support

On Fri, 28 Apr 2023 at 05:17, Alexander Pravdin <alex.pravdin@interi.co> wrote: > On Thu, 27 Apr 2023 at 07:03, Rowan Tommins <rowan.collins@gmail.com> > wrote: > > > You have to load the value somehow; bcmath accepts strings directly, so > > parses the values each time, which isn't very efficient; but php-decimal > > uses strings to construct objects, as does GMP. I guess the other option > > for a decimal would be a pair of integers (whole part and fractional > part). > > They all have to use strings because this is the only way in PHP to > represent a decimal value. No, they all have to use strings because *you've got to tell the computer what value you want*. I think you may be muddling a few different questions: 1) How is the value stored *internally*? In any extension or core code, this can be whatever binary representation you want; generally, it will be a representation used by some third-party library, unrelated to anything else in PHP. 2) What options does the user have for *creating* values, based on other types? This is purely a design decision: if the authors of php-decimal wanted to implement a function that took a PHP float and returned a Decimal value, it could do so, with no changes in PHP. They have made the decision not to, for the reason I quoted from their manual. 3) How is the type *presented to the user*? For bcmath, the internal representation is created on-demand, and hidden from the user completely. For php-decimal, the internal representation is wrapped in a PHP object, so that the user can pass it around, and use PHP's existing type system to reason about it. For a new scalar type, the only immediate difference would be that functions like is_object() would return false; it would still be a PHP wrapper around some other internal representation. Note that this is unrelated to the previous two points: the bcmath functions could be changed to accepted string|float as their input, and still not expose what conversion they do internally; or we could introduce a BCNum object, which parsed the string in its constructor, and have the functions accept that. 4) What *syntax* is available for creating values? This *does* require core support, e.g. to support something like 1.23d However, note that ultimately your PHP source file is a string of characters, so all that's happening with such a syntax is that the compiler takes the characters "1.23", and calls the same internal implementation as would be used for new Decimal("1.23"). There might be a performance boost of not allocating as many intermediate structures, but mostly, it's just "syntax sugar" - it doesn't allow you to do anything that existing syntax can't. 5) What *functionality* is available, once you have a value? As shown by GMP, it is already possible for an extension to create an object that works with a lot of arithmetic and other operators. New functions can be written accepting the type, and/or methods added to its class definition. The only thing that's not possible without core changes is accepting the new type in existing functions. Regards, -- Rowan Tommins [IMSoP]