[RFC] Deprecate dynamic properties View as Markdown

On Wed, Aug 25, 2021 at 7:46 AM Rowan Tommins rowan.collins@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 is a bold move, and in principle seems sensible, although I'm
slightly scared how many places will need fixing in legacy code bases.

I have a couple of concerns with using stdClass as the opt-in mechanism:

• The name of that class already leads to a lot of confusion about its
  purpose - it's not actually "standard" in any way, and new users seeing
  it as a base class are even more likely to mistake it as some kind of
  "universal ancestor". Would it be feasible to introduce an alias like
  "DynamicObject" which more clearly defines its role?

• Adding a parent to an existing class isn't always possible, if it
  already inherits from something else. Perhaps the behaviour could also
  be available as a trait, which defined stub __get and __set methods,
  allowing for the replacement of the internal implementation as you've
  described?

Regards,

--
Rowan Tommins
[IMSoP]

--

To unsubscribe, visit: https://www.php.net/unsub.php

Although not having voting karma, I'm +1 on this.

I've always preferred explicit over implicit code as it makes the learning
path to newcomers a lot easier to grasp.

When we talk about legacy code, more frequently than not is that legacy
code is unlikely to run on the latest version of PHP,
thus I'm not entirely sure if that's a super strong argument against it,
but I may be missing something.

--
Atenciosamente,

Flávio Heleno

HI Nikita,

What if you consider this instead? Rather allowing STD class as an
exception to dynamic properties, why not introduce STDAbstract?

interface STDClassInterface
{
public function __get(string $name) : mixed;
public function __set(string $name, mixed $value = null) : mixed;
/* * other magic methods */
};
abstract class STDClassAbstract implements STDClassInterface {/* *
interface methods */}
Class STDClass extends SDTClassAbstract{}
``

Best
Hamza


> 
>> 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 is a bold move, and in principle seems sensible, although I'm
> slightly scared how many places will need fixing in legacy code bases.
>
> I have a couple of concerns with using stdClass as the opt-in mechanism:
>
> * The name of that class already leads to a lot of confusion about its
> purpose - it's not actually "standard" in any way, and new users seeing
> it as a base class are even more likely to mistake it as some kind of
> "universal ancestor". Would it be feasible to introduce an alias like
> "DynamicObject" which more clearly defines its role?
>
> * Adding a parent to an existing class isn't always possible, if it
> already inherits from something else. Perhaps the behaviour could also
> be available as a trait, which defined stub __get and __set methods,
> allowing for the replacement of the internal implementation as you've
> described?
>
>
> Regards,
>
> --
> Rowan Tommins
> [IMSoP]
>
> --
> 
> To unsubscribe, visit: https://www.php.net/unsub.php

• Adding a parent to an existing class isn't always possible, if it
  already inherits from something else. Perhaps the behaviour could also
  be available as a trait, which defined stub __get and __set methods,
  allowing for the replacement of the internal implementation as you've
  described?

Couldn't this be easily done in userland with the ArrayLikeObject (an
example in the RFC) or something similar, just done as a trait? Maybe
having an example trait implementation that basically "imitates"
stdClass in terms of dynamic properties would be helpful to show in the
RFC, to highlight a possible resolution path for legacy code with this
problem. This could be an example implementation:

trait DynamicPropertiesTrait
{
    private array $dynamicProperties = [];
    public function &__get(string $name): mixed { return
$this->dynamicProperties[$name]; }
    public function __isset(string $name): bool { return
isset($this->dynamicProperties[$name]); }
    public function __set(string $name, mixed $value): void {
$this->dynamicProperties[$name] = $value; }
    public function __unset(string $name): void {
unset($this->dynamicProperties[$name]); }
}

On Wed, Aug 25, 2021 at 12:45 PM Rowan Tommins rowan.collins@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 is a bold move, and in principle seems sensible, although I'm
slightly scared how many places will need fixing in legacy code bases.

I have a couple of concerns with using stdClass as the opt-in mechanism:

• The name of that class already leads to a lot of confusion about its
  purpose - it's not actually "standard" in any way, and new users seeing
  it as a base class are even more likely to mistake it as some kind of
  "universal ancestor". Would it be feasible to introduce an alias like
  "DynamicObject" which more clearly defines its role?

• Adding a parent to an existing class isn't always possible, if it
  already inherits from something else. Perhaps the behaviour could also
  be available as a trait, which defined stub __get and __set methods,
  allowing for the replacement of the internal implementation as you've
  described?

So, a few thoughts: First of all, I should say that "extends stdClass" is
not so much an explicit escape hatch I built into this, it's more something
that arises naturally: We obviously need to keep support for dynamic
properties on stdClass, and if we do so, I would expect that to apply to
subclasses as well. As such, I believe that the "extends stdClass" escape
hatch is something that's going to work anyway -- the only question would
be whether we want to provide additional opt-ins in the form of
interfaces/traits/attributes/etc.

Second, I consider "extends stdClass" to be something of a last-ditch
option. If you encounter a dynamic property deprecation warning, you should
generally resolve it in some other way, and only fall back to "extends
stdClass" as the final option.

All that said, yes, we could add a trait. It would basically be
ArrayLikeObject from the RFC with "class" replaced by "trait". However, I'm
not sure this is really worthwhile. The nice thing about extending stdClass
is that it a) gives you much more efficient property access than
__get/__set and b) matches current behavior. Implementing such a trait,
even if bundled, doesn't really give you any advantages over implemening
__get/__set yourself. It would not make use of an optimized implementation
(or at least, the implementation would still be calling real __get/__set
methods) and the behavior would be limited to what the trait provides. A
custom implementation is not significantly harder (the minimal
implementation is five lines of code) but gives you more control, e.g. you
might want just the minimal implementation, or you might want to also
support Traversable, have a custom __debugInfo(), etc.

My preliminary position would be that if a) you can't avoid dynamic
properties in any other way and b) you can't extend stdClass either, then
you should go with c) implementing __get/__set yourself, as appropriate for
the given use-case.

Regards,
Nikita

On Wed, Aug 25, 2021 at 4:26 PM tyson andre tysonandre775@hotmail.com
wrote:

Hi Nikita Popov,

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.

I'd had some concerns.

It might be too soon after your addition of WeakMap.
https://www.php.net/weakmap was introduced in PHP 8.0 (and WeakReference
in 7.4),
so applications/libraries fixing the deprecation may need to drop support
for php 7.x early.
Applications attempting to polyfill a WeakMap in earlier PHP versions
would potentially leak a lot of memory in php 7.x.

• I don't know how many minor versions to expect before 9.0 is out
• Is it feasible for a developer to create a native PECL polyfill for
  WeakMap for earlier PHP versions that has a
  subset of the functionality the native weak reference counting does?
  (e.g. to only free polyfilled weak references when cyclic garbage
  collection is triggered and the reference count is 1).

For compatibility with < PHP 7.4 in this use case I'd suggest to either
suppress the deprecation for a particular assignment, or to pick the used
mechanism depending on PHP version.

We don't have an official schedule for major versions, but going by the
last few releases, I'd guess that it happens after PHP 8.4, or around that
time :) I think an approximate PECL polyfill (that tries to free on GC)
would be possible, but I'm not sure it would really be useful relative to
having version-dependent behavior.

Additionally, it makes it less efficient (but still feasible) to associate
additional fields
with libraries or native classes/PECLs you don't own (especially for
circular data structures), especially if they need to be serialized later.

Efficiency probably depends on the case here -- while I'd expect the
dynamic property to be more efficient on access than the WeakMap, it will
likely also use more memory, sometimes much more.

(it isn't possible to serialize WeakMap, and the WeakMap would have fields
unrelated to the data being serialized)
I guess you can have a wrapper class that iterates over a WeakMap to
capture and serialize the values that still exist in SplObjectStorage,
though.
(Though other languages do just fine without this functionality)

Right, the WeakMap approach will not impact the serialization of the
object, as well as other property based behaviors, such as comparison
semantics. I would usually count that as an advantage (what you do
shouldn't impact the behavior of 3rd-party classes), but there's probably
use cases for everything :)

I'm not sure if a library owner would want to change their class hierarchy
to extend stdClass (to avoid changing the behavior of anything using $x instanceof stdClass) and the attribute/trait approach might be more
acceptable to library owners.
E.g.
https://github.com/vimeo/psalm/blob/master/src/Psalm/Internal/Analyzer/Statements/Expression/Call/FunctionCallAnalyzer.php
would set a dynamic property $stmt->pure in
PhpParser\Node\Expr\FuncCall $stmt in a vendor dependency on php-parser.

I wouldn't want library authors to change their class hierarchy for
3rd-party use cases, unless those use cases are actually fundamental to the
library in some way. For PHP-Parser this is actually the case, which is why
it offers the Node::setAttribute() API. The intended way to do this would
be $stmt->setAttribute('pure', true) in this case.

Regards,
Nikita

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

I am overall in favor of this move and making declared-only the default. What I'm still undecided on is what escape hatch should be allowed. I agree that "you can extend stdClass already" isn't a good one, because that isn't viable in many cases.

The most viable options in my mind are "use __get/__set yourself, you heathen" and an attribute. The benefit of an attribute over an interface or new parent class is that it's silently backward compatible, especially since attributes are comments in <8.0 versions, so legacy code can add that marker and still be compatible with anything from 5.0 on.

The "internal impact" section makes me lean toward the "__get/__set" option, but I don't fully understand the benefits of the impact. It seems it would make the engine a little tidier and more efficient, but I don't have a good sense for how much more efficient, which would need to be balanced against how much more INefficient user-space code with dynamic properties would become. (Either using __get/__set itself, or inheriting from a future stdClass that implements them internally.) IMO we should prioritize engine efficiency over edge-case efficiency (which dynamic properties are these days), but the amount still matters.

I'm currently working on some improvements to the FIG to allow it to release small, incomplete code libraries or shared type libraries. Perhaps a fully user-space BC trait with the basic behavior (basically what's shown in the RFC) could live there? (Not speaking on FIG's behalf, here, just musing aloud.)

--Larry Garfield

Sara Golemon wrote on 8/25/21 10:28:

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 { ... }

I like this approach.

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'd feel better about this if we had that citation. In modern code, I
agree they are probably rare, but I think there's a lot of legacy code
that makes heavy use of dynamic properties as an important feature of
PHP. (I'm working on one such project right now.)

Cheers,
Ben

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 crux of the issue is what our end goal is:

1. Require users to explicitly annotate classes that use dynamic
   properties, but otherwise keep dynamic properties as a fully supported part
   of the core language.
2. Remove support for dynamic properties entirely. The core language only
   has declared properties and __get/__set, and nothing else. stdClass is just
   a very efficient implementation of __get/__set.

The RFC is currently written under the assumption that the end goal is (2).
To support that, I believe that "extends stdClass" and "use
DynamicProperties" are the only viable approaches. The former, because it
inherits stdClass behavior, the latter because it's literally __get/__set.
An attribute would require retaining the capability to have arbitrary
classes with dynamic properties.

Now, if the actual goal is (1) instead, then I fully agree that using a
#[SupportsDynamicProperties] attribute is the ideal solution. It can be
easily applied anywhere and has no BC concerns. Heck, someone who just
doesn't care could easily slap it on their whole codebase without spending
brain cycles on more appropriate solutions.

I do think that just (1) by itself would already be very worthwhile. If
that's all we can reasonably target, then I'd be fine with the
#[SupportsDynamicProperties] solution. Though if (2) is viable without too
many complications, then I think that would be the better final state to
reach.

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.

I think the argument isn't quite symmetric: A 3rd-party library in
maintenance-only mode has essentially no incentive to go out of their way
and add a "locked" keyword/attribute to their classes. Adding some missing
property declarations to keep working on new PHP versions is a different
matter.

Regards,
Nikita

On Mon, Aug 30, 2021 at 2:14 PM Côme Chilliet <
come.chilliet@fusiondirectory.org> wrote:

Le Wed, 25 Aug 2021 12:02:49 +0200,
Nikita Popov nikita.ppv@gmail.com a écrit :

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

If I understand correctly the RFC, in these two classes:

class A {
public $prop;

public function __construct() {
    unset($this->prop);
}

}

class B {
public $prop;
}

The property $prop is not in the same state in the end? What is the
difference?
isset returns FALSE for both, no? And property_exists?

In the latter case, the property has value null. In the former case, it is
unset. In both cases, it is declared. Accessing an unset property will
trigger __get/__set. Accessing a null property will not (assuming it is
visible).

Is it something that was the same before the RFC and would be different

after,
or is it already two different cases and how?

This RFC does not have any impact on this behavior. This is a "standard"
pattern used for lazy initialization.

Regards,
Nikita

Based on the received feedback, I've updated the RFC to instead provide an
#[AllowDynamicProperties] attribute as a way to opt-in to the use of
dynamic properties. As previously discussed, this won't allow us to
completely remove dynamic properties from the language model anymore, but
it will make the upgrade path smoother by avoiding multiple inheritance
issues.

Quoting the updated RFC:

We may still wish to remove dynamic properties entirely at some later
point. Having the #[AllowDynamicProperties] attribute will make it much
easier to evaluate such a move, as it will be easier to analyze how much
and in what way dynamic properties are used in the ecosystem.

But in this place it does not mention PHP 9.0. Other places still
mention converting it to an error for PHP 9.0. Is that still the plan?

Based on the received feedback, I've updated the RFC to instead provide an
#[AllowDynamicProperties] attribute as a way to opt-in to the use of
dynamic properties. As previously discussed, this won't allow us to
completely remove dynamic properties from the language model anymore, but
it will make the upgrade path smoother by avoiding multiple inheritance
issues. Especially given recent feedback on backwards-incompatible changes,
I think it's prudent to go with the more conservative approach.

I think it would still be the biggest compatibility break since PHP
4->5. Adding a custom property is a common way for an extension to
attach data to an object generated by an uncooperative application or
library.

As the RFC notes, you could migrate to WeakMap, but it will be very
difficult to write code that works on both 7.x and 8.2, since both
attributes and WeakMap were only introduced in 8.0. In MediaWiki
pingback data for the month of September, only 5.2% of users are on
PHP 8.0 or later.

Also, in the last week, I've been analyzing memory usage of our
application. I've come to a new appreciation of the compactness of
undeclared properties on classes with sparse data. You can reduce
memory usage by removing the declaration of any property that is null
on more than about 75% of instances. CPU time may also benefit due to
improved L2 cache hit ratio and reduced allocator overhead.

So if the point of the RFC is to eventually get rid of property
hashtables from the engine, I'm not sure if that would actually be a
win for performance. I'm more thinking about the need for a sparse
attribute which moves declared properties out of properties_table.

I would support an opt-in mechanism, although I think 8.2 is too soon
for all core classes to opt in to it. We already have classes that
throw an exception in __set(), so it would be nice to have some
syntactic sugar for that.

-- Tim Starling

Dear Internals,

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

--
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

On Mon, Nov 15, 2021 at 11:26 AM Nicolas Grekas <
nicolas.grekas+php@gmail.com> wrote:

Hi Nikita, hi everybody,

Le mer. 25 août 2021 à 12:03, Nikita Popov nikita.ppv@gmail.com a écrit
:

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.

Thanks for the RFC, it makes sense to me and I support the move.

Since Symfony is mentioned in the RFC, I thought you might want to know
about this PR, that removes dynamic properties from the Symfony codebase:
https://github.com/symfony/symfony/pull/44037/files

What Nikita describes in the RFC is correct: declaring+unsetting the
"groups" property works.
There's just one more thing I had to do; I also had to replace two calls to
property_exists:

•    if (!property_exists($this, 'groups')) {
  

•    if (!isset(((array) $this)['groups'])) {
  

The rest are test cases where we've been lazily accepting fixtures with
undeclared properties. No big deal, and I'm happy the engine might soon
help us get a bit stricter in this regard.

I read that some think that this PR is not required because static
analysers (SA) can report when a dynamic property is used. Although that's
correct, I think it would be detrimental to PHP as a language if SA tools
(or any tools actually) were a requirement to code in the safe-n-modern
way. You should not have to install any complex safeguarding tooling
infrastructure to start coding; both for newcomers, but also for
no-so-new-comers.

Its not so true from my POV that static analysis can avoid having this
deprecation:

1. static analysis does not work for dynamic assignments,

$object = new SomeDataObject();
$row = $pdo->fetch();
foreach ($row as $column => $value) {
$object->$column = $value;
}

arguably this is one of the important use cases this deprecation fixes.

A second example of this is when doing deserialization into an object from
JSON or XML:

$object = new SomeDataObject();
$objectPayload = json_decode($input, true);
foreach ($objectPayload as $prop => $value) {
$object->$prop = $value;
}

This doesn't apply sole to user input where maybe more validation of input
is necessary, but also for mapping config files to an object.

All this kind of generic code cannot be statically analysed, but this
deprecation and removal has the most value in exactly that use-case.

About the discussion related to deprecations. I've yet to see a better
reporting system than the current one.
It's true that too many userland error handlers are throwing instead of
collecting/logging/skipping deprecations.
But these can be fixed (and many are being fixed these days, which is
nice!)

Cheers,
Nicolas

If a 3rd party package combines fixing major bugs with a release of a
significant version and including also the new attribute that's available
only on newer PHP version?

Just to be clear, attributes are designed in such a way that you, and
third-party packages, can add this attribute right now, in your PHP
7.4 code, with no ill effects. In older versions, it's a comment (as
long as it's on its own line); and in 8.0 and 8.1 it will be parsed as
an attribute, but simply do nothing.

You can add the attribute to every single class, and slowly remove it
when you're confident of each class not needing it; or you can collect
the E_DEPRECATED messages and add the attribute to every class
mentioned. Even in PHP 9.0, there will be no subtle behaviour
differences; the code will either run, or you will get an error in
exactly the same circumstances as the E_DEPRECATED messages.

Regards,

--
Rowan Tommins
[IMSoP]