Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:123081 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 8039D1A009C for ; Wed, 10 Apr 2024 07:24:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1712733898; bh=uv4JPjiEtqgGppRJyM0XO/xtAxzTYy0pmurN7vz6nH0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=aYNHYuuGhthwLu345a9LACOJhezTSQlR8CcSbC+Q8sxxPHStUcc8+8rn5iBWj9mUB 2MjvutulpNyC6AnwB+QZQVev7+MLvdqKKsIMmdhEe1iUflLl4mzsmimjC0QcKV0H1g nl6LBoV3jyzW0SO+6qarJWdo1ZsWcFw/8AGSDxvoMFl+DmFGDb8sZOlpykdkz4b4Bc uCRxUcUrTmUN7EZ4PDqMiGrPVZ/KfdMnxyTRiprIgayGmvuNnbe3Jnmok+PdRqdG8c lBOyTRSJ2sEF9f6zupOU1rtFjTy4xXb8ozpFfXPUpkcxrUREO+RLODv7NLbPW3ZZMC jgPoDF62Oci3Q== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id F281B180044 for ; Wed, 10 Apr 2024 07:24:57 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE,URIBL_SBL_A autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: No X-Envelope-From: Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com [209.85.128.52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 10 Apr 2024 07:24:57 +0000 (UTC) Received: by mail-wm1-f52.google.com with SMTP id 5b1f17b1804b1-41745acb8f4so1446275e9.0 for ; Wed, 10 Apr 2024 00:24:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1712733864; x=1713338664; darn=lists.php.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=uv4JPjiEtqgGppRJyM0XO/xtAxzTYy0pmurN7vz6nH0=; b=F5wsObXQSvLAYNCabI9aILXpxbJCI8rOeyrJwF6hgFJfqNqzUxZOFMOwDTxBWME0TN 0cIqOtTJyUoSRpasE4Wq6xal3COFVdYMfSv5z38NjcToJAd5Kqf1UXElhL2xcWd2Amsw Mvij8qkv3RWc7LpPhL3Qux9nF8hlJKG1m5/wCQ4bv2LhiRhxkAeeHlUaB+xKdJvgh7mj HlSCvhFx38acXMY6a/semCGzfGCW1QBb2aO0rZU/T/s2yeNOthZyC/7izNImIOGWR1F7 GG4IY/IvfHqx3NAKMeHTNYDbWsxxkmY9WkTMateIdqHBUpHL2unC8Mnm1fL86zHwz+qH ydYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1712733864; x=1713338664; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uv4JPjiEtqgGppRJyM0XO/xtAxzTYy0pmurN7vz6nH0=; b=JKIvhJGRV6Nko4GzUmAYOUr+KG1NPjDvVWQWj7V1SfO1goa0tKWlTEXnNpj4eZgcVL BJAXc3vMjhMr5xKxW8mMU960kgsXUqZVfudV3FKo70uc7olvY/NCOCdy9uunIiNoBJ/o HCOagXh5dpnJg4bEy1Usu6GA34/m0l8pjxXcmPSqdtvriyYNKLpEhxs+MxYiywrfCL4O 2j6fkdYgJcdHlPKQ3bd9S6zuW1di/SZ95mLogaSSXsPrsWY3oH+XFFNHTwIcP0EejT4v I7f4gqwVOJ9vRUoAQLNUTE3MMhwIDXKIn0eGHXbxMt+IKSc15WKeKy3JZp5QAjeBvEhh m05A== X-Gm-Message-State: AOJu0YwReogR+M6+KpdrODE9M/PiA/urucgRSbfUtJdk4aCyuWogwOvG IEvAB4YqtbJ9C5yYJRhNJvX9bdFl+rPZWKIOQE781rv42eR+QSgkCJ1/49gfHw9vSoGNUSoC/+J XpOuPFvbPX29YiNEfizKHu8ITI9d0rIjr X-Google-Smtp-Source: AGHT+IEi0Svh7BAvLVRtUqEQyy4xsP+ZWLH+yJLnZcQyAGMQrjtLkyGKA1a4OHCXke/2CHper6VhjqC8tmvK54kFdVg= X-Received: by 2002:a05:600c:260d:b0:416:9cf8:f901 with SMTP id h13-20020a05600c260d00b004169cf8f901mr1370444wma.17.1712733863655; Wed, 10 Apr 2024 00:24:23 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 References: <40553F28-2EC2-475A-BD8E-1D6517AA2A51@rwec.co.uk> <2B518F62-B774-45C9-82A2-EF6653AAE34E@sakiot.com> <0f3d0f89-3064-4d56-9fb2-801bb0cda8a5@rwec.co.uk> <9FEBB00C-A51A-40D6-A18D-593C78938BCA@rwec.co.uk> In-Reply-To: <9FEBB00C-A51A-40D6-A18D-593C78938BCA@rwec.co.uk> Date: Wed, 10 Apr 2024 10:23:47 +0300 Message-ID: Subject: Re: [PHP-DEV] Native decimal scalar support and object types in BcMath - do we want both? To: "Rowan Tommins [IMSoP]" Cc: internals@lists.php.net Content-Type: multipart/alternative; boundary="00000000000089c7710615b8edb4" From: arvids.godjuks@gmail.com (Arvids Godjuks) --00000000000089c7710615b8edb4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, 9 Apr 2024 at 09:57, Rowan Tommins [IMSoP] wrote: > > > On 8 April 2024 21:51:46 BST, Jordan LeDoux > wrote: > >I have mentioned before that my understanding of the deeper aspects of h= ow > >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 numbe= r > 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 fo= r > that purpose, shows over 200 lines to check: > https://heap.space/search?project=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 > then all of those code paths are considered for you, you just have a fixe= d > 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. --=20 Arv=C4=ABds Godjuks +371 26 851 664 arvids.godjuks@gmail.com Telegram: @psihius https://t.me/psihius --00000000000089c7710615b8edb4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, 9 Apr 2024 at 09:57, Rowan To= mmins [IMSoP] <imsop.php@rwec.co= .uk> wrote:


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 intr= oductions like https://www.phpinternalsbook.com/ and in this ca= se Nikita's blog articles about the changes in 7.0: https://www.npopov.com/2015/05/05/I= nternal-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 abl= e 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 most= ly be handled in a few key functions and macros - but the sheer number of p= laces that do something different with each zval type and will need updatin= g. Searching for Z_TYPE_P, which is just one of the macros used for that pu= rpose, shows over 200 lines to check: https://heap.= space/search?project=3Dphp-src&full=3DZ_TYPE_P&defs=3D&refs=3D&= amp;path=3D&hist=3D&type=3Dc

That's why it's so much easier to wrap a new type in an object, bec= ause then all of those code paths are considered for you, you just have a f= ixed set of handlers to implement. If Ilija's "data classes" = proposal progresses, you'll be able to have copy-on-write for free as w= ell.

Regards,
Rowan Tommins
[IMSoP]

So I'd like to conclude this thread s= ince we have dedicated threads for each of the topics here.

<= div>In my opinion, we should go with both. Both topics cover quite differen= t 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 ge= tting into an industry where it would be required to have numbers that larg= e). But I am interested in a native decimal that would cover the vast major= ity 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 an= d continue there.

--

Arv=C4=ABds Godjuks
+371 26 851 664
arvids.god= juks@gmail.com
Telegram: @psihius=C2=A0https://t.me/psihius
--00000000000089c7710615b8edb4--