Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:123051
Feedback-ID: id5114917:Fastmail
Date: Tue, 09 Apr 2024 07:56:28 +0100
To: internals@lists.php.net
Subject: =?US-ASCII?Q?Re=3A_=5BPHP-DEV=5D_Native_decimal_scalar_support_?=
 =?US-ASCII?Q?and_object_types_in_BcMath_-_do_we_want_both=3F?=
User-Agent: K-9 Mail for Android
In-Reply-To: <CAMrTa2FeSTGE9rRdeMVzULkmn4C-LQ0GC8upDtEx1JEo6A0LFA@mail.gmail.com>
References: <40553F28-2EC2-475A-BD8E-1D6517AA2A51@rwec.co.uk> <2B518F62-B774-45C9-82A2-EF6653AAE34E@sakiot.com> <A703D145-1A10-4C7E-9E0C-1F0BEF94CF99@rwec.co.uk> <CAMrTa2G+_v1aO_g7NLiLsTwquJaf9=Zj5bp2ODGzVSB3iGr6pw@mail.gmail.com> <0f3d0f89-3064-4d56-9fb2-801bb0cda8a5@rwec.co.uk> <CAMrTa2HgSSTT1wJPz0x4X=nW2ijQDmaGhdNGKx1rLePdBWGfwQ@mail.gmail.com> <c3663fb3-1a78-4077-80b9-8431119fbb96@rwec.co.uk> <CAMrTa2FeSTGE9rRdeMVzULkmn4C-LQ0GC8upDtEx1JEo6A0LFA@mail.gmail.com>
Message-ID: <9FEBB00C-A51A-40D6-A18D-593C78938BCA@rwec.co.uk>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: imsop.php@rwec.co.uk ("Rowan Tommins [IMSoP]")



On 8 April 2024 21:51:46 BST, Jordan LeDoux <jordan=2Eledoux@gmail=2Ecom> =
wrote:
>I have mentioned before that my understanding of the deeper aspects of ho=
w
>zvals work is very lacking compared to some others, so this is very
>helpful=2E

My own knowledge definitely has gaps and errors, and comes mostly from int=
roductions like https://www=2Ephpinternalsbook=2Ecom/ and in this case Niki=
ta's blog articles about the changes in 7=2E0: https://www=2Enpopov=2Ecom/2=
015/05/05/Internal-value-representation-in-PHP-7-part-1=2Ehtml


> I confess that I do not
>understand the technical intricacies of the interned strings and packed
>arrays, I just understand that the zval structure for these arbitrary
>precision values would probably be non-trivial, and from what I was able =
to
>research and determine that was in part related to the 64bit zval limit=
=2E

From=20previous discussions, I gather that the hardest part of implementing =
a new zval type is probably not the memory structure itself - that will mos=
tly be handled in a few key functions and macros - but the sheer number of =
places that do something different with each zval type and will need updati=
ng=2E Searching for Z_TYPE_P, which is just one of the macros used for that=
 purpose, shows over 200 lines to check: https://heap=2Espace/search?projec=
t=3Dphp-src&full=3DZ_TYPE_P&defs=3D&refs=3D&path=3D&hist=3D&type=3Dc

That's why it's so much easier to wrap a new type in an object, because th=
en all of those code paths are considered for you, you just have a fixed se=
t of handlers to implement=2E If Ilija's "data classes" proposal progresses=
, you'll be able to have copy-on-write for free as well=2E

Regards,
Rowan Tommins
[IMSoP]