Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116340 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 5187 invoked from network); 13 Nov 2021 10:31:59 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 13 Nov 2021 10:31:59 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 59AD31804DB for ; Sat, 13 Nov 2021 03:26:10 -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=0.8 required=5.0 tests=BAYES_20,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,FREEMAIL_REPLY, 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-ed1-f51.google.com (mail-ed1-f51.google.com [209.85.208.51]) (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 ; Sat, 13 Nov 2021 03:26:07 -0800 (PST) Received: by mail-ed1-f51.google.com with SMTP id o8so48407526edc.3 for ; Sat, 13 Nov 2021 03:26:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:subject:to:cc:message-id:in-reply-to:references :mime-version; bh=jKxbNdFLVo2GZinjuXmNM7GX7poh0Zq3q1cXrJDwzG0=; b=IvehxDgk93FwLmP/mVUfnFgj/Lu38RW3EgfgiBG7qqveezjSApjKdR93jexxMwuqB2 IN+NedaaeX+Q3+OlS0HAEn+dgAwxaFT2DxlF4j2I3ofS2nXP0cgCX//Qq2n4kjJUmGkP 1yaavw5KFG6K+RE8mhVxEPIVPKdHxh+xajh2zUImYXNrLW32sjO7ABnL1+rjPVNM93su 2pX6+f41VIrWiGQtI+PvLZ6DXpRiDy823WbjlbsNnbIzPMftgfGtVQB6bJk2gioI84gh 9XC+yeNzmOqwTJS2F5iwSgGCUZUtldqOlcUdcDp7GakfiDaZBWCf/SvPTnDYo8A2z48w wLyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:subject:to:cc:message-id:in-reply-to :references:mime-version; bh=jKxbNdFLVo2GZinjuXmNM7GX7poh0Zq3q1cXrJDwzG0=; b=xDsA65C88lmo47wQUY+Kz+DoDydjHOCtFfep23LbDLEC2lF8QV9MreKY7WDQVkPsTV cdYuAw/uCHRii83KqGBJ2c5xtx5SnrfpAxkENk3Fpjao1Ff9WqGeESzlpJ1/cbfqCHz2 knmm+XPVwHy5HefMJuxnCNkHP1rDV+7kbtrh8HflLUWNt5bTND7ABgrsCdop96TVdIZ5 7ATxZRAEHJh7CPM3s8US7gKhuLx/bBPQLJCoMP6Kgz11Yr2vOEx3TWKxXVWzJ0Jpb5V2 /scHDLmHSFDMQwn7dwlKNSRrvwi2FjMa/ETnxksJ82SdYvcEp0i91Avnm4GBGzdPkE3Z 1t5g== X-Gm-Message-State: AOAM530GQDh8joUQF6DsZumZjGaJYDLijU1LczqJ3EK/p5FxyTP15uXg sDY9aCPZKt/Amdr3/iLriow= X-Google-Smtp-Source: ABdhPJxo1CiodY93us0m4rnXkvZTsg77WQ29Dgp4/5GsJTwbqANQomdeFGnJY6bCRuX7lF98xdbPhg== X-Received: by 2002:a17:907:9196:: with SMTP id bp22mr3906436ejb.69.1636802765739; Sat, 13 Nov 2021 03:26:05 -0800 (PST) Received: from [192.168.1.102] ([85.149.141.157]) by smtp.gmail.com with ESMTPSA id n16sm732003edt.67.2021.11.13.03.26.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 13 Nov 2021 03:26:05 -0800 (PST) Date: Sat, 13 Nov 2021 12:25:58 +0100 To: Peter Bowyer Cc: php internals Message-ID: In-Reply-To: References: <6e2d3e92-b53a-8264-85c6-d2d0062ee449@gmx.de> X-Mailer: geary/3.38.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=-WY0fpCp/2ozMVnS98Qme" Subject: Re: [PHP-DEV] [VOTE] Deprecate dynamic properties From: crocodile2u@gmail.com (Victor Bolshov) --=-WY0fpCp/2ozMVnS98Qme Content-Type: text/plain; charset=us-ascii; format=flowed The way I see it, it might look similar to strict_types opt-in, but only on the surface. The amount of changes needed to make legacy code compliant with strict_types directive, would be tremendous, also there would be no simple one-size-fits-all solution like the #[AllowDynamicProperties]. In that sense, these two are hardly comparable. I agree with the change (not that I have a voting karma, just watching). I also agree with Andreas Heigl saying that at certain point changes like this probably should happen, and regardless of exactly when, it is going to cause debate and complaints, but we as community should probably prefer having a long deprecation cycle for smoother transition, which is why the suggested timeline is IMO good (that is, if the community represented by core devs will vote for this RFC). Opt-in strategy - #[DenyDynamicProperties] - for a change like this would effectively do nothing. I personally would be against this change at all then. Many thanks to the PHP team from userland, also for letting anyone voice their thoughts and concerns on important matters! Regards, Victor Bolshov, Software developer On za, nov 13, 2021 at 08:26, Peter Bowyer wrote: > On Sat, 13 Nov 2021, 00:14 Christoph M. Becker, > wrote: > >> Offering an >> opt-out of dynamic properties or some switch to disable the >> deprecation >> would not help in that regard. >> > > Given this is a big change to the way PHP has behaved for decades I > did > wonder why the RFC didn't propose an opt-out of dynamic properties > rather > than opt-in, preserving the long-term language behaviour. So thanks > for > covering that. > > I think you and the PHP internals community will be surprised by how > widely > used dynamic properties are. I read through a handful of WordPress > plugins > we have installed and found a few. And in my own where I'm using a > named > class instead of an array. > > I work with modern framework based code most of the time and I find > it easy > to forget what is out there as quintessential or traditional PHP code. > > Whether we have #[AllowDynamicProperties] or #[DenyDynamicProperties] > one > set of PHP users is going to be doing a find & replace across their > codebase. > > From a DX perspective I'd rather have #[DenyDynamicProperties] as > it's like > declaring strict_mode and opt-in. > > Either way are the planned engine changes feasible, as the feature of > dynamic properties stays in the language but toggled off/on per class? > > Peter > >> --=-WY0fpCp/2ozMVnS98Qme--