On Fri, 28 Apr 2023 at 05:17, Alexander Pravdin <alex.prav...@interi.co>
wrote:
> On Thu, 27 Apr 2023 at 07:03, Rowan Tommins <rowan.coll...@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]
