On Sun, Apr 28, 2024 at 11:36 AM Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> wrote: > > > > 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]
I'm not so sure this could be implemented as an extension, there just isn't the right hooks for it. Robert Landers Software Engineer Utrecht NL
