Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123225
Precedence: bulk
MIME-Version: 1.0
References: <18c42fdbb30.2831.17a3710df6d58f02ca570cc47e197a63@interi.co>
 <0f64523d-d949-75ed-682b-789fc33fa3b2@php.net> <CAOyH9yRfFBKis_eoMp=V_Y8+03yrqg=rMtJMbd+ifeJUwkGczw@mail.gmail.com>
 <CAOyH9ySpRv9uTj5+p7JzE=j1f49gO6N4W73NYSse7Ax1VYjd3Q@mail.gmail.com> <AD712363-98FA-4B95-BBD1-30B2B0CD2BE5@rwec.co.uk>
In-Reply-To: <AD712363-98FA-4B95-BBD1-30B2B0CD2BE5@rwec.co.uk>
Date: Sun, 28 Apr 2024 16:47:40 +0200
Message-ID: <CAPzBOBP5rCixsk8kzrvfeFwBL7Yio0KLKF2bhCSthsN=h6+iBA@mail.gmail.com>
Subject: Re: [PHP-DEV] Proposal: Arbitrary precision native scalar type
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: landers.robert@gmail.com (Robert Landers)

On Sun, Apr 28, 2024 at 11:36=E2=80=AFAM Rowan Tommins [IMSoP]
<imsop.php@rwec.co.uk> wrote:
>
>
>
> On 28 April 2024 07:02:22 BST, Alexander Pravdin <alex.pravdin@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 w=
hat use cases you are trying to cater for, and who your audience is. Only t=
hen can you define a minimum set of requirements and goals.
>
> It seems to me that the starting point would be an extension with a decim=
al type as an object, and implementations for all the operations you want t=
o 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 t=
o 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 sema=
ntics rather than eager cloning. See Gina's recent thread about "data class=
es".
>
> - Overloading existing functions which accept floats with decimal impleme=
ntations. 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(de=
fault_decimal), or having (decimal) casts affecting the tree of operations =
below them rather than just the result. This just needs the type to be avai=
lable to the compiler, not a new zval type - for instance, anonymous functi=
on syntax creates a Closure object.
>
> There may be other parts I've not mentioned, but hopefully this illustrat=
es the idea that "a native decimal type" doesn't have to be one all-or-noth=
ing 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