On Wed, Aug 25, 2021 at 5:03 AM Nikita Popov <nikita....@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 “locked” is the default state, while classes that require
dynamic
> properties are a rare exception. Additionally, this requires that class
owners
> (which may be 3rd party packages) consistently add the “locked” 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
