On Tue, 30 Apr 2024 at 09:19, Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> wrote:
> > > On 28 April 2024 07:47:40 GMT-07:00, Robert Landers < > landers.rob...@gmail.com> wrote: > > >I'm not so sure this could be implemented as an extension, there just > >isn't the right hooks for it. > > The whole point of my email was that "this" is not one single feature, but > a whole series of them. Some of them can be implemented as an extension > right now; some could be implemented as an extension by adding more hooks > which would also be useful for other extensions; some would need changes to > the core of the language. > > If the aim is "everything you could possibly want in a decimal type", it > certainly can't be an extension; if the aim is "better support for > decimals", then it possibly can. > > Regards, > Rowan Tommins > [IMSoP] > I think setting some expectations in the proper context is warranted here. 1. Would a native decimal type be good for the language? I would say we probably are not going to find many if any people who would be against it. 2. Is there a need for it? Well, the whole world of e-commerce, accounting and all kinds of business systems that deal with money in PHP world do not leave any room for doubt - https://packagist.org/?query=money . The use case is right there :) 3. In most cases people need decimal precision math in the bounds of what the decimal128 standard provides. Most of us just do not want the float drift and while a signed 64-bit integer is big, it has it's limitations and a need for edge layer transformations be it presentation, API endpoints or storing it in the database or other storage mediums. 4. Is it a lot of engine work? Yes, yes it is. Is it worth it? I think yes, especially if we get buying from most of the active maintainers and get a project going for it. This is not going to be the first or last big engine project. But this might warrant a PHP 9 release in the end :) 5. But BCMath/GMP/etc!!! Well, extensions are optional. They are also not as fast and they deal with strings. They are not as fast and you will have to rely on that extension's methods that most math functions are implemented and all that stuff. Frankly, I never had a use case where BCMath was not an overkill. And doing number crunching with BCMath is just slow due to them being strings internally. The use cases are just different. They solve a different problem than a decimal128 does for the language. I think all the discussions on the subject have shown that BCMath RFC is it's own thing and adding a decimal type to the PHP language/engine is it's own thing. They are not mutually exclusive and solve different problems. -- Arvīds Godjuks +371 26 851 664 arvids.godj...@gmail.com Telegram: @psihius https://t.me/psihius
