Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:119241 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 92468 invoked from network); 7 Jan 2023 03:37:47 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 7 Jan 2023 03:37:47 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 759181801FD for ; Fri, 6 Jan 2023 19:37:46 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-pl1-f175.google.com (mail-pl1-f175.google.com [209.85.214.175]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 6 Jan 2023 19:37:46 -0800 (PST) Received: by mail-pl1-f175.google.com with SMTP id d3so3698434plr.10 for ; Fri, 06 Jan 2023 19:37:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=SHuFMjrkPwqe+o6nFCz/MtrA+dDrIsIQud7tRV7eVpU=; b=myVonx+/wmxy+b0ZU7iXeYDitE+hujAXqIKvp93C36xsRHouXObKkRW+dJF8Y4NCJ4 a153yXJD+h8s/neBgkok5d9eLmE7ET4XxlQfdxtz2GNLDyrQ1fFoWYxRWe2jnqKiANUX H2uPqKH4AVAET1mWw3Vg+OR+bnys6DVaS66n3G93i07/DHSWnrFYrxvifasB7lgaIwaf 5TcOIloUsiyMrz/T4wAmKewgeZBLHfV0FN6jqklt5H4FfxrOCuulndsifDkZTJ1dVgVP wkx8+KxgKDyRtAtVXu+GdGOypKEmqfyRPi69w4Cz8+w/UjejUCq0pZsKE5w7/kM9+nAZ eKlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=SHuFMjrkPwqe+o6nFCz/MtrA+dDrIsIQud7tRV7eVpU=; b=rdQMsRnPjDaMGc3hEoZvMZ6Q+8QBdk+7Iqvi4vTVyBbrGDf0UcDpPY6qIoTTnkfSqd yVGZ5Kq1AQueFkMVeVHTN/nsuQ5nZccyWD4esfH+8vT+VF4kIt2ri1qHm4nx/6g8Ac2C bjXocBishUEbTO1aAForISzgdpA/QG3hesTugLKet7zg2uoA7JjjDV+fqasAeRucR57t 2VcDoCr+QY8CITFWZJLdvBEY5qRPPcOgfV4vGyNUxWPpmx2FBpJhI+xtxFF8CtOK2XYf wi1rn1Pj/iXo8qBYW57j6kJkP5Cda+LTTEsiOtW57f3xSAJJc03kW2MlXh107scjKdWL R3Zw== X-Gm-Message-State: AFqh2kq1zbdtjKfS0lVB9DHimwan7tfH7tPGZq8OTRI9dDQcnvmRuClA qsOVryLvnv962R0AI54Jj94afGM84h5lPjdRltw= X-Google-Smtp-Source: AMrXdXsjZx+MTq5JVHMNz9xZCRZYY7HOGLDwHwB0VCYL+QgWZbNuEfVFxaYIMwAkIjMdRVbZjceRNO0JM6v2gM+lKJg= X-Received: by 2002:a17:902:c10a:b0:17c:5b01:f227 with SMTP id 10-20020a170902c10a00b0017c5b01f227mr2285812pli.3.1673062664841; Fri, 06 Jan 2023 19:37:44 -0800 (PST) MIME-Version: 1.0 References: <5bc98f87-4ee6-8eb8-7952-8a4bb12dbada@gmx.de> In-Reply-To: <5bc98f87-4ee6-8eb8-7952-8a4bb12dbada@gmx.de> Date: Sat, 7 Jan 2023 03:37:33 +0000 Message-ID: To: "Christoph M. Becker" Cc: Thomas Hruska , PHP Development Content-Type: multipart/alternative; boundary="000000000000d32f5b05f1a441aa" Subject: Re: [PHP-DEV] Re: A set of 18 functions/changes to improve PHP core From: george.banyard@gmail.com ("G. P. B.") --000000000000d32f5b05f1a441aa Content-Type: text/plain; charset="UTF-8" On Fri, 6 Jan 2023 at 16:19, Christoph M. Becker wrote: > On 06.01.2023 at 17:01, Thomas Hruska wrote: > > > Pre-implemented as an extension (sort of) w/ a preliminary test suite to > > validate the implementations: > > > > https://github.com/cubiclesoft/php-ext-qolfuncs > > > > I probably violated some coding style guidelines and a few things are > > bound to ruffle some feathers. Be gentle? But all input is generally > > useful. > > Thank you! At least some of that looks interesting to me. I'll try to > have a closer look; maybe filing issues on GH is preferable to > discussing all the details on this ML. > > > I attempted to sign in with my existing PECL credentials on wiki.php.net > > (user: cubic) but that didn't work. Attempting to create a Wiki > > account for my possibly already existing user resulted in two error > > messages: An empty message box and another message box saying "The user > > could not be created." > > > > Requesting RFC karma for user 'cubic' (cubic@php.net) if possible. > Thanks. > > That is not possible, since you already have a PHP account. Note that > these are completely separate from PECL accounts (although users usually > have the same nicknames for both accounts). To log in to the Wiki, you > need your PHP account password. In case you have it forgotten, use > . > > > I assume I'll need to create up to 18 separate RFCs unless one RFC is > > somehow fine? Not sure how this should be divvied up yet. > > Maybe a compromise is in order, and you can split it into a couple of > RFCs. Maybe not; I haven't checked closely so far. > > -- > Christoph M. Becker > I think splitting into "component" RFCs might make more sense as there are some string, image, 2D matrices, variable and hash things which are logical delimitations between these function additions. I've had a cursory read of the README most seem reasonable, I have my doubts about the matrix functions (see below) and str_realloc() (but that might just be the naming and how it's meant to be use with str_splice which is confusing me) About str_splice(), why not call it str_modify() as the behaviour seems to be subtly different from its array equivalent array_splice()? About matrices: We already have a couple of issues supporting them that we probably should address those first, namely that multiplication is assumed to be commutative, something which is not true for matrices (see https://github.com/php/php-src/pull/9218) Hoping I get back to argue about the former, it would make it possible to use objects and the fact extensions can overload operators to make dealing with matrices easier. This is IMHO a better approach than using multidimensional arrays, which those functions also seem to limit to the (albeit very useful) 2*2 case. Anyhow, best of luck with the RFCs. Best regards, George P. Banyard --000000000000d32f5b05f1a441aa--