On 28 April 2024 07:02:22 BST, Alexander Pravdin <alex.prav...@interi.co> wrote:
>Hello everyone. To continue the discussion, I'm suggesting an updated
>version of my proposal.
This all sounds very useful ... but it also sounds like several months of
full-time expert development.
Before you begin, I think it will be really important to define clearly what
use cases you are trying to cater for, and who your audience is. Only then can
you define a minimum set of requirements and goals.
It seems to me that the starting point would be an extension with a decimal
type as an object, and implementations for all the operations you want to
support. You'll probably want to define that more clearly than "anything in the
language which takes a float".
What might seem like it would be the next step is converting the object to a
"native type", by adding a new case to the zval struct. Not only would this
require a large amount of work to start with, it would have an ongoing impact
on everyone working with the internals.
I think a lot of the benefits could actually be delivered without it, and as
separate projects:
- Optimising the memory performance of the type, using copy-on-write semantics
rather than eager cloning. See Gina's recent thread about "data classes".
- Overloading existing functions which accept floats with decimal
implementations. Could potentially be done in a similar way to operator
overloads and special interfaces like Countable.
- Convenient syntax for creating decimal values, such as 0.2d,
declare(default_decimal), or having (decimal) casts affecting the tree of
operations below them rather than just the result. This just needs the type to
be available to the compiler, not a new zval type - for instance, anonymous
function syntax creates a Closure object.
There may be other parts I've not mentioned, but hopefully this illustrates the
idea that "a native decimal type" doesn't have to be one all-or-nothing project.
Regards,
Rowan Tommins
[IMSoP]
