On Tue, 9 Apr 2024 at 09:57, Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> wrote:
> > > On 8 April 2024 21:51:46 BST, Jordan LeDoux <jordan.led...@gmail.com> > wrote: > >I have mentioned before that my understanding of the deeper aspects of how > >zvals work is very lacking compared to some others, so this is very > >helpful. > > My own knowledge definitely has gaps and errors, and comes mostly from > introductions like https://www.phpinternalsbook.com/ and in this case > Nikita's blog articles about the changes in 7.0: > https://www.npopov.com/2015/05/05/Internal-value-representation-in-PHP-7-part-1.html > > > > 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. > > From previous discussions, I gather that the hardest part of implementing > a new zval type is probably not the memory structure itself - that will > mostly 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 > updating. Searching for Z_TYPE_P, which is just one of the macros used for > that purpose, shows over 200 lines to check: > https://heap.space/search?project=php-src&full=Z_TYPE_P&defs=&refs=&path=&hist=&type=c > > That's why it's so much easier to wrap a new type in an object, because > then all of those code paths are considered for you, you just have a fixed > set of handlers to implement. If Ilija's "data classes" proposal > progresses, you'll be able to have copy-on-write for free as well. > > Regards, > Rowan Tommins > [IMSoP] > So I'd like to conclude this thread since we have dedicated threads for each of the topics here. In my opinion, we should go with both. Both topics cover quite different things. Personally, I'm not really interested in BCMath part as much because I do not see me needing it (never did before, don't force me getting into an industry where it would be required to have numbers that large). But I am interested in a native decimal that would cover the vast majority of the uses and be on part with integer and float number types. If my stance makes sense, I then shall join the native decimal thread and continue there. -- Arvīds Godjuks +371 26 851 664 arvids.godj...@gmail.com Telegram: @psihius https://t.me/psihius
