Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:127611 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 lists.php.net (Postfix) with ESMTPS id DA9831A00BC for ; Thu, 5 Jun 2025 14:42:03 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1749134400; bh=1UPHsjwna2wrY6WmuOY/8r2zi2y77nCaxE3gC+yH7UY=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=OEtSbUW0x3ph1Dul+/0jA6aZpdEaVW/uY3zTVpNeLZzaaNTb2kV4OyUa2GZ3h3a2b I7fzo+4Ud+oOg8wupgj+1y9lnl++4tg1d65vBrALmDhUqnvFpQn/flkB0G4VH+1Qwn odNdyOe9Rt3+7NhW0bW+jAUUL0XvYqGJfn5vGyPf0Y4yeJngufEb4LS9cPbeD2Byiv zXsKQ+daSVQrWx8vP1atR3YRkOuznUHNjKTGuuvBQeaSPWqN5ihf/pv53isFQk3t+d s5+3lwyorymSO9z7l0QrH8Fpt23xClrOEp6LgjdaMT1jr0spqgvuLOnyU9raMIg1ZG 5E9RpeiK1fDHQ== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 6CFA618002F for ; Thu, 5 Jun 2025 14:39:59 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_MISSING,HTML_MESSAGE, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) (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 ; Thu, 5 Jun 2025 14:39:59 +0000 (UTC) Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-adb5fd85996so206119566b.2 for ; Thu, 05 Jun 2025 07:42:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tideways-gmbh.com; s=google; t=1749134521; x=1749739321; 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=1sdvQxXHg8EOR9Pcon+6msiMHSz1c5odQYCmMhxD9Mo=; b=LTrue7L55XRM/1uotfToXeGcO45F9pMrGeeFrTE/8L+DPo1NGenXuGnDrR9LhK6Do6 KDqgLjFChPmWh03TQqtbYxp40+1Yz1PfP/3L/SIXkh9CxW2wC9mN3rtat6ngYIWnMU8+ JnfjDb38EqbA7nRnJhlbLnG4KAS5y2vwQIylX9zNjncNABg2FRs9jLU13k0Icxw7IoOr Dx2Qy2cZzX1sc80yhy+WpxapbE9nQgHW/tr+ZWdljLed+iQxojXT1Yk9AaKxNEkejK08 H0Ys74mcQp89YvBApHJlWNNArrBHqRxBeCckAVH17G7Ttzjyz9iB1ZuS7wXjEtWx8yHS SCeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1749134521; x=1749739321; 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=1sdvQxXHg8EOR9Pcon+6msiMHSz1c5odQYCmMhxD9Mo=; b=A2NriX7yJl34QdZuC059NS9H+yeFa0YeBYIQU1wTHQpGR06hboc7+x7wbUrWTmUiTv NGcd1M4/jhzHfdmU1ch82jnCLz47fFCo6QFjtfHs5KHifIHGlwPNz1nmuzFMj+4xLcRi T6preju4/kcfUXmngQs1ibBFb/cE7IjFr1NbyQt27iDbqWTaAPw8yejiwmve4RiyEbsI H/v7XzuNB41C/AwIZdLyIoqY0U7diVHItGWdORC208es1q4Sv6VgvQNK3T/LfY9OLClO 3kx0r5X3R71ZJ1tUd4Fp1hLdIogF3I8kTQpWhdGRNmyQTrze4yYvdheuhr6oe/2crEIU VO6Q== X-Gm-Message-State: AOJu0Yx3ShEq2McH06Hr2GVqW/7AV6AN56168l9QsLESeGjmD/1Ac8gH BT/G6Mqe30fYDNitoo5sbbA4/wv3xjD87fTUPopeXuI0JI/N1UTGgNtB20c8QedvV4Sa/wKRslP 4/KbyifTJKP4T74g8LvXMIthDpGVf5E8GWm3KffiwOfrs/7Z8qztX8ac= X-Gm-Gg: ASbGnctIdpOvsBq541EMucHc1C+wnlyS6tEpPGl12x/HdJaD8WZmC8xk4lPYGFskTSZ xZFoNQWO0+kqRRZAsYHsl1qUGqO+mh2gmskQ2M8kV//ktk9r3vHPFyun2JOnTQvG8sQ56Lr4eE/ i2rvIgWshKXsiZjCnUJ6RclQOosawc4hYiOwtPVz1NrBpDwB3YZEPXG951txxpdvUQv2uvG19Mf Q== X-Google-Smtp-Source: AGHT+IHwJLGw5atRvXHtQFhikL0UEhcMFkNnBC4QM9WhVak8OqihnEPPXfAcwnQ3M5tV84xhmKQZFYmZytP8KOTgxXY= X-Received: by 2002:a17:906:f295:b0:ade:5ba:40e6 with SMTP id a640c23a62f3a-ade05ba425bmr322005466b.18.1749134520976; Thu, 05 Jun 2025 07:42:00 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net x-ms-reactions: disallow MIME-Version: 1.0 References: In-Reply-To: Date: Thu, 5 Jun 2025 16:41:49 +0200 X-Gm-Features: AX0GCFt8SPq2dPridGLxYW1qPv2vbU6psZmJ8uI2CfVZiAx9MvabPVkbJeqt2Mw Message-ID: Subject: Re: [PHP-DEV] [VOTE] Clone with v2 To: Larry Garfield Cc: php internals Content-Type: multipart/alternative; boundary="000000000000c99dd90636d41d8f" From: volker@tideways-gmbh.com (Volker Dusch) --000000000000c99dd90636d41d8f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 4, 2025 at 6:41=E2=80=AFPM Larry Garfield wrote: > While I support this RFC and want to see it in, I have voted no for 2 > reasons. > > 1. The switch to an array parameter, as previously noted, is a major DX > loss for unclear benefit. It's just all-around a worse design, and "mayb= e > we can change how arrays work in the future" is not an answer. > It is frustrating that you claim the benefits to be unclear after multiple long explanations, when this was thankfully unearthed during RFC discussion= . Inventing a new syntax for this specific function call is something, I couldn't go forward with this, and I think we explained well why in the thread. But to sum up again for the benefits of readers: Using a ...variadic to generate a key-value array is something php-src doesn't do *anywhere* currently, and it has multiple issues and edge cases. It is making the language more inconsistent and harder to use. Adding this special syntax for a single function is unacceptable to me. While it looks nicer to people who don't use or like PHP arrays much, an array is PHP's, especially php-src's, main way of passing a list of key-value pairs. While vibes-based language design is tempting, and I've fallen for it initially in this RFC. I want to work with the reality of how PHP works here and not leave all problems coming from this to the core team. The alternative syntax would introduce extra documentation effort, inconsistency in how PHP core functions work, and generate bug reports stemming from the edge cases outlined. I'd rather not have the feature at all than burden maintainers with this. Especially given how negligible the difference is in typing effort is in the end, and how it doesn't change static analysis or IDE support. But I know we disagree on that point. This RFC is also leaving room for future improvement by still allowing to add further parameters if the unforeseen need for this should come up. Ideas around changing PHPs syntax for key-value pair lists shouldn't have been attached to this in the first place. Extracting the ideas from this discussion into things like `#[NamedParameterOnly]`, a potential 3rd array syntax `[foo: "bar"]` people argued for, or ideas like this https://github.com/php/php-src/pull/18613 . But none of this has a place in clone-with as introducing a new way of defining an array here instead of somewhere generic isn't something I feel helps PHP. > 2. There was still an active discussion with Nicolas going on that seemed > rather important. Opening the vote while that was still going on is, as > noted above, problematic. > > --Larry Garfield > We answered the concerns multiple times in the discussion, including declaring it out of scope in the initial RFC text and explaining the issues with adding parameters to __clone in the discussions. This RFC also leaves these, very much out of scope for this RFC, open in the future. They would massively increase the scope of this and require a ton of discussion that killed the first attempt at incremental improvement already. So from my perspective, there was no active discussion going on as nobody else spoke up for a week and nothing changed with Nicolas, admittedly regrettably timed, last email. Which we also answered in detail. So I fail to see how this problematic. Letting the RFC peter out and die in the discussion, like so many others, is not a desired outcome for me and as this implementation doesn't block any future improvements or make anything worse in userland. Regards, Volker --=20 Volker Dusch Head of Engineering Tideways GmbH K=C3=B6nigswinterer Str. 116 53227 Bonn https://tideways.io/imprint Sitz der Gesellschaft: Bonn Gesch=C3=A4ftsf=C3=BChrer: Benjamin Au=C3=9Fenhofer (geb. Eberlei) Registergericht: Amtsgericht Bonn, HRB 22127 --000000000000c99dd90636d41d8f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 4, 2025 at 6:41=E2=80=AFPM La= rry Garfield <larry@garfieldte= ch.com> wrote:
While I support this RFC and want to see it in, I have voted no for 2 reaso= ns.

1. The switch to an array parameter, as previously noted, is a major DX los= s for unclear benefit.=C2=A0 It's just all-around a worse design, and &= quot;maybe we can change how arrays work in the future" is not an answ= er.

It is frustrating that you claim th= e benefits to be unclear after multiple long explanations, when this was th= ankfully unearthed during RFC discussion.
Inventing a new syntax = for this specific function call is something, I couldn't go forward wit= h this, and I think we explained well why in the thread.=C2=A0
But to sum up again for the benefits of readers: Using a ...va= riadic to generate a key-value array is something php-src doesn't do anywhere currently, and it has multiple issues and edge cases. It is m= aking the language more inconsistent and harder to use. Adding this special= syntax for a single function is unacceptable to me. While it looks nicer t= o people who=C2=A0 don't use or like PHP arrays much, an array is PHP&#= 39;s, especially php-src's, main way of passing a list of key-value pai= rs.
While vibes-based language design is tempting, and I've f= allen for it initially in this RFC. I want to work with the reality of how = PHP works here and not leave all problems coming from this to the core team= . The alternative syntax would introduce extra documentation=C2=A0effort, i= nconsistency in how PHP core functions work, and generate bug reports stemm= ing from the edge cases outlined. I'd rather not have the feature at al= l than burden=C2=A0maintainers with this. Especially given how negligible= =C2=A0the difference is in typing effort is in the end, and how it doesn= 9;t change static analysis or IDE support. But I know we disagree on that p= oint.

This RFC is also leaving room for future imp= rovement by still allowing to add further parameters if the unforeseen need= for this should come up.=C2=A0

Ideas around chang= ing PHPs syntax for key-value pair lists shouldn't have been attached t= o this in the first place. Extracting the ideas from this discussion into t= hings like `#[NamedParameterOnly]`, a potential 3rd array syntax `[foo: &qu= ot;bar"]` people argued for, or ideas like this https://github.com/php/php-src/pull/18613 . But none of this has a place in clone-with as introducing a new way of= defining an array here instead of somewhere generic isn't something I = feel helps PHP.
2. There was still an active discussion with Nicolas going on that seemed r= ather important.=C2=A0 Opening the vote while that was still going on is, a= s noted above, problematic.

--Larry Garfield



--
Volker Dusch
Head of Engineerin= g
Tideways GmbH
K=C3=B6nigswinterer Str. 116
53227 Bonn

Sitz der Gesellschaft: Bonn
Gesch=C3= =A4ftsf=C3=BChrer: Benjamin Au=C3=9Fenhofer (geb. Eberlei)
Regist= ergericht: Amtsgericht Bonn, HRB 22127
--000000000000c99dd90636d41d8f--