Re: Native decimal scalar support and object types in BcMath - do we want both?

On 8 April 2024 21:51:46 BST, Jordan LeDoux <jordan.ledoux@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]