Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:115807 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 67386 invoked from network); 25 Aug 2021 10:54:34 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 25 Aug 2021 10:54:34 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 255FB1804DB for ; Wed, 25 Aug 2021 04:28:46 -0700 (PDT) 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,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS13238 5.45.192.0/18 X-Spam-Virus: No X-Envelope-From: Received: from forward108j.mail.yandex.net (forward108j.mail.yandex.net [5.45.198.253]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Wed, 25 Aug 2021 04:28:45 -0700 (PDT) Received: from myt5-6f58ffe13ff5.qloud-c.yandex.net (myt5-6f58ffe13ff5.qloud-c.yandex.net [IPv6:2a02:6b8:c12:3998:0:640:6f58:ffe1]) by forward108j.mail.yandex.net (Yandex) with ESMTP id 439233F22E3B for ; Wed, 25 Aug 2021 14:28:42 +0300 (MSK) Received: from myt5-aad1beefab42.qloud-c.yandex.net (myt5-aad1beefab42.qloud-c.yandex.net [2a02:6b8:c12:128:0:640:aad1:beef]) by myt5-6f58ffe13ff5.qloud-c.yandex.net (mxback/Yandex) with ESMTP id vZuKQXfGKI-SgHi4eYs; Wed, 25 Aug 2021 14:28:42 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=php.watch; s=mail; t=1629890922; bh=vukCmU12WEXa81Pl7F6/VfhHPpwIG6qxhxo13Akg7oU=; h=To:Subject:From:Date:References:Cc:Message-ID:In-Reply-To; b=clLgNvaaJA1WsGdiH6XO8keaLUJV/JzHH2whFwL71wprxku7hX3A4HEmKRfj1I1Sp 8mWPoqMoftaseJJ5/lRUYH3T59wxV7KMBkF2VN4D/CJqMSZYPMmPMxawL6D5mboN1D pGP4L5IioL1vGxY0gghVSW6lXg9Wnw6VLlG1xF6k= Authentication-Results: myt5-6f58ffe13ff5.qloud-c.yandex.net; dkim=pass header.i=@php.watch Received: by myt5-aad1beefab42.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id KGWhwDHeEE-SfOuYC5S; Wed, 25 Aug 2021 14:28:41 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Received: by mail-ot1-f41.google.com with SMTP id i3-20020a056830210300b0051af5666070so44697243otc.4 for ; Wed, 25 Aug 2021 04:28:41 -0700 (PDT) X-Gm-Message-State: AOAM533o0dQnO+tGFXOJvHSzyEnLCuqv8XgbfxPvDMn/IPaMZTA3kU6B 6pgOC++b7YDDeBbGlQOsh0Qm+5VXX1+CONjNowU= X-Google-Smtp-Source: ABdhPJwsbWwc7pwHIc/lo5bjJ8x4kkGcmwcqfjMXDnRsNo9CFV39fDHO6gpCdd+f92tdGNYK4esLFH1ZNFFVitD+LcI= X-Received: by 2002:a9d:5787:: with SMTP id q7mr37297536oth.353.1629890919994; Wed, 25 Aug 2021 04:28:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: Date: Wed, 25 Aug 2021 16:58:13 +0530 X-Gmail-Original-Message-ID: Message-ID: To: Nikita Popov Cc: PHP internals Content-Type: text/plain; charset="UTF-8" Subject: Re: [PHP-DEV] [RFC] Deprecate dynamic properties From: ayesh@php.watch (Ayesh Karunaratne) > > Hi internals, > > I'd like to propose the deprecation of "dynamic properties", that is > properties that have not been declared in the class (stdClass and > __get/__set excluded, of course): > > https://wiki.php.net/rfc/deprecate_dynamic_properties > > This has been discussed in various forms in the past, e.g. in > https://wiki.php.net/rfc/locked-classes as a class modifier and > https://wiki.php.net/rfc/namespace_scoped_declares / > https://github.com/nikic/php-rfcs/blob/language-evolution/rfcs/0000-language-evolution.md > as a declare directive. > > 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. > > Regards, > Nikita Hi Nikita, Thanks for opening this, I'm very supportive of this. Having some Drupal and other legacy background, I'm afraid this could disrupt a lot of Drupal applications, which uses dynamic properties quite extensively in its Entity APIs, Views, etc. I totally agree that it is a bad practice, but that's what half a million or so Drupal 7 web sites do. Perhaps, we can make it an easy to opt-in with a keyword (`locked class Foo {}`) or an interface (`Foo implements LockedClass {}`), or provide an easy opt-out (similar to the tentative return type attribute)? Thank you, Ayesh.