Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116388 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 23587 invoked from network); 15 Nov 2021 19:10:56 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 15 Nov 2021 19:10:56 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id BD237180384 for ; Mon, 15 Nov 2021 12:05:41 -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 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-ua1-f43.google.com (mail-ua1-f43.google.com [209.85.222.43]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Mon, 15 Nov 2021 12:05:41 -0800 (PST) Received: by mail-ua1-f43.google.com with SMTP id b17so37545641uas.0 for ; Mon, 15 Nov 2021 12:05:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=njEhw9Rd5uM8XVaLKqH3Q0ShgtHBAJoZA82tFe2l6EE=; b=B2EltjJh3Y3wjplDwEBrzaJ0Jp3HHP+8fL9ZW19Fvy+wVJglrNE52yScNZZI/QG2GN IQ9r4RH5D5klItzs8eHFlY36238iTp5yfom4/fUzBgJEApQAgoMLw3m7plZXYDe0usd/ A3mjZT8+Uf+K5k3qc3TEdY29S+4NjIccDfUi14ykhKqLI3Rwu5JMU777+WywPUg6WAxe UnAwcZsub5gYoojde889AkxDnJPtZRNozMTRxbZRvJ8k6Ef615imZv9OLqtroPRf5e4A 83vDjkOqSylDRrfGxB0xHB/FXowF0vGfqpKE/fBPF0z1DkLPwPa8t0BJch3fex20uS9d Z9pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=njEhw9Rd5uM8XVaLKqH3Q0ShgtHBAJoZA82tFe2l6EE=; b=nv+hi3JDyWRGmpJ2iRfMyVezrkRakWLeMEdShG+RE/P15jBT+uv4SJ3qQ7PdgDqmU1 MbXM05QdMR1Q4oWLXzpzPlMXeT+l5PnsoBugX1pOtWwXjvGtXU3OgfRBuCBBvvs0ZQCQ jcGv+9lyVyzHEO2R+re6qcpdgSVN/HPuy8DvBa0Az8KNs1eAWZ2DIrWuhI5jKpDh6WPQ EJccya49R60gLoqJOnbkUEoP6cPyBjM7KLLVE7Jqcrm7hXG6076d9AJ5upWLyySD8cio 6in/V+pb2RbcCKYtC36VAmXCMjt8dk1lMNDMNcUXZ9cPT/RtTwEfmP+Vykf/UdjogMlu 736A== X-Gm-Message-State: AOAM532YJE/U0bZg2QwlWEuiWAvZWutIwWcHzVXIRXHOF/U1u24Zdfse MbFu6so1y1OTKDDBpDcu1dAxIGjdPxuVf5trQdRSBiq49WA= X-Google-Smtp-Source: ABdhPJxZ8OKsDt+iDrKMvFMTq3U4Rvop/uh2OumJjQmGCacr2ae5R7Kuk3CNNgNEGEa+NzKkXzfV67d2s5UxE2672i8= X-Received: by 2002:ab0:750c:: with SMTP id m12mr2100438uap.119.1637006740412; Mon, 15 Nov 2021 12:05:40 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: Date: Mon, 15 Nov 2021 15:05:28 -0500 Message-ID: To: James Gilliland Cc: Derick Rethans , PHP internals , Nikita Popov Content-Type: multipart/alternative; boundary="00000000000041dc9005d0d955f4" Subject: Re: [PHP-DEV] Re: [RFC] Deprecate dynamic properties From: chasepeeler@gmail.com (Chase Peeler) --00000000000041dc9005d0d955f4 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 15, 2021 at 3:02 PM James Gilliland wrote: > On Mon, Nov 15, 2021 at 3:53 AM Derick Rethans wrote: > > > Dear Internals, > > > > On Wed, 10 Nov 2021, Nikita Popov wrote: > > > > > On Wed, Aug 25, 2021 at 12:02 PM Nikita Popov > > wrote: > > > > > > > This RFC takes the more direct route of deprecating this > > > > functionality entirely. I expect that this will have relatively > > > > little impact on modern code (e.g. in Symfony I could fix the vast > > > > majority of deprecation warnings with a three-line diff), but may > > > > have a big impact on legacy code that doesn't declare properties at > > > > all. > > > > > > > > > > I plan to open voting on this RFC soon. Most of the feedback was > > > positive, apart from the initial choice of opt-int mechanism, and that > > > part should be addressed by the switch to the > > > #[AllowDynamicProperties] attribute. > > > > The voting is now open, but I think one thing was not taken into account > > here, the many small changes that push work to maintainers of Open > > Source library and CI related tools. > > > > In the last few years, the release cadence of PHP has increased, which > > is great for new features. It however has not been helpful to introduce > > many small deprecations and BC breaks in every single release. > > > > This invariably is making maintainers of Open Source anxious, and > > frustrated as so much work is need to keep things up to date. I know > > they are *deprecations*, and applications can turn these off, but that's > > not the case for maintainers of libraries. > > > > Before we introduce many more of this into PHP 8.2, I think it would be > > wise to figure out a way how to: > > > > - improve the langauge with new features > > - keep maintenance cost for open source library and CI tools much lower > > - come up with a set of guidelines for when it is necessary to introduce > > BC breaks and deprecations. > > > > I am all for improving the language and making it more feature rich, but > > we have not spend enough time considering the impacts to the full > > ecosystem. > > > > I have therefore voted "no" on this RFC, and I hope you will too. > > > > cheers, > > Derick > > > > I appreciate that Derick. I know there have been some pretty big efforts > required for some recent php updates in Drupal. And I've mentioned in a > couple threads on Twitter but Drupal requires a pretty heavy change to > support this. It adds properties to classes _outside_ its codebase which > means none of the mitigations in the RFC apply. It was on my radar when the > vote popped up because the system in question has long been known to be > less than ideal but "php wouldn't ever remove this ancient feature right?" > and every other option is just a ton more complicated. I've talked with > some maintainers and it looks like we're going to deal with the cost of > converting the system but if this dirty hack hadn't been on our radar it > could have really hurt. Like maybe not getting the fix in place before the > next major release in time for backwards compatibility commitments bad. > > So I worry what sort of earthquake this might trigger through libraries. > Like, I'm pretty sure the OpenApiGenerator templates used dynamic > properties for some things so how many little internal libraries are going > to have to be regenerated? What other lightly maintained library are people > going to be stuck waiting to update because someone's CI didn't catch the > deprecation? > By design my REST API utilizes dynamic properties. I've always found it to be a feature of PHP, not a bug. > > I think this sort of change is probably for the better, but I worry about > how disruptive this could end up being. > -- Chase Peeler chasepeeler@gmail.com --00000000000041dc9005d0d955f4--