Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115819
MIME-Version: 1.0
References: <CAF+90c9_qu=PiTS81J2mesPfJdz7n5nSi3qoLNLjhEGN-aTytA@mail.gmail.com>
In-Reply-To: <CAF+90c9_qu=PiTS81J2mesPfJdz7n5nSi3qoLNLjhEGN-aTytA@mail.gmail.com>
Date: Wed, 25 Aug 2021 10:28:00 -0500
Message-ID: <CAESVnVqMfxSZxG1+k+_o+HZ1B7QbH=wDeMTQm8R-Ok_bEyqSRA@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000ed145605ca63e50e"
Subject: Re: [PHP-DEV] [RFC] Deprecate dynamic properties
From: pollita@php.net (Sara Golemon)

--000000000000ed145605ca63e50e
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Aug 25, 2021 at 5:03 AM Nikita Popov <nikita.ppv@gmail.com> wrote:
> 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 RFC offers `extends stdClass` as a way to opt-in to the use of
dynamic properties.
>
This makes the assumption that existing uses of dynamic properties are all
root classes. I don't think that assumption can be made.

> Some people have suggested that we could use a magic marker
> interface (implements SupportsDynamicProperties),
> an attribute (#[SupportsDynamicProperties])
> or a trait (use DynamicProperties;) instead.
>
My gut-check says an Attribute works well enough.  This will unlock the
class (disable deprecation warning) in 8.2+ and be ignored in earlier
releases (8.0 and 8.1 would need an auto-loaded polyfill userspace
attribute obviously, but that's a tractable problem).

#[SupportsDynamicProperties]
class Foo { ... }

> The Locked classes RFC took an alternative approach to this problem space=
:
> Rather than deprecating/removing dynamic properties and providing an
opt-in
> for specific classes, it instead allowed marking specific classes as
locked in
> order to forbid creation of dynamic properties on them.
>
> I don't believe that this is the right strategy, because in contemporary
code,
> classes being =E2=80=9Clocked=E2=80=9D is the default state, while classe=
s that require
dynamic
> properties are a rare exception. Additionally, this requires that class
owners
> (which may be 3rd party packages) consistently add the =E2=80=9Clocked=E2=
=80=9D keyword
> to be effective.
>
I struggle here, because the opt-in approach is the most BC, but I actually
think you're right.  I think[citation needed] that dynamic props are
probably rare enough that as long as the escape hatch is clear, we can be a
little more bold about nudging the ecosystem forward.  I will counter
however, that the same issue with 3rd party libraries applies to opt-out as
opt-in.  A third party library that's undermaintained (and uses dynamic
props) won't be able to be used out of the box once we apply this.  I don't
think that's enough to scare us off, it just means that the opt-in side of
that argument cancels out.

-Sara

--000000000000ed145605ca63e50e--