Hi
[reordering the quoted parts for this reply to read more nicely]
On 6/22/26 23:41, Juliette Reinders Folmer wrote:
The fact that you even feel the need to point out that "deprecations
are
not a breaking change" is extremely offensive in and of itself.
It is insofar relevant that deprecations have zero immediate impact.
There might be an impact once the actual removal happens, but users have
at least 4 years until the PHP version that first made them aware that
something is deprecated goes out of (security) support and they might be
required to upgrade to a PHP version where the deprecated functionality
changed or was removed. It is not unlikely that a product or application
will be retired before the four years are over.
The fact that one out of twentyfive proposals has some vague statement
about the impact, without any details of what was analysed or how,
without definition of "insignificant", and without a link to details
giving credibility to that statement, only goes to highlight that these
proposals lack a proper impact analysis.
The sentence in question contains a link to the RFC where the analysis
was made. The “Backward Incompatible Changes” section of that RFC
contains concrete numbers. The corresponding RFC discussion - which is
linked in the RFC - provides additional information with regard to the
methodology (in https://news-web.php.net/php.internals/129074).
And generally speaking an “Impact Analysis”, particularly one that is
based on analyzing existing code, cannot capture any positive impact the
deprecation (and ultimate removal) has on the ecosystem.
As an example the “Passing objects which are interpreted as arrays”
proposals (which I would count as one) are proposing to deprecate
something that is fundamentally broken by allowing to violate core
engine assumptions and where straight-forward alternatives are suggested
in the deprecation message. This kind of deprecation feels like the
PHP-equivalent of passing a law to specifying the ban of sale of Tobacco
to folks born after “4 years from now”, which I think some countries
already did. Sure this ban will lead to folks in the Tobacco industry
losing their job, because of the ever-shrinking market, but they are
being provided a 4-year heads-up and some of the employees might even be
retired then. And the benefits to the society (and e.g. the health
system) far outweigh the drawbacks of keeping the Tobacco industry and
associated jobs. And to close the loop to PHP: The core developers are
the health workers of the language (and engine) and keeping such a
fundamentally broken feature alive means they will have to continue to
deal with the most obscure of bug reports resulting from this.
For things like deprecating `is_long()`, the positive impact is
certainly smaller. But here there is a “positive impact” to be had in
making it easier for users to learn PHP. It would be a reasonable
interpretation for `is_long()` to mean “a large value” or for
`is_double` to mean “is an array containing two elements”. With the
expectation that PHP will keep being relevant for the next thirty years
and counting and programming being more approachable and relevant than
ever, I'd say it's a reasonable claim that there will be more PHP code
written in the next 30 years than has been written in the past 30 years
and thus something that the benefit to new users is weighing more
heavily than the cost to existing users.
Other than that, I did not express an opinion on the details of the
individual proposals.
I am thus taking issue with the *unconditional* request of an “impact
analysis”, which will inherently be biased due to the inability to
capture and measure anticipated positive impact and thus will not help
make the reader make a more informed decision.
Is there some *specific* proposal where you feel there is a stark
mismatch between the cost for existing code and the benefit in making
the language easier to learn / the benefit in pointing out possible
unnoticed mistakes in existing code / the language more maintainable for
the core developers and where you feel extra research or justification
might be warranted?
As Gina said in her email in the PHP 8.4 deprecation discussion
(https://news-web.php.net/php.internals/124428): Deprecations are not
being proposed because the author gets enjoyment out of causing extra
work to PHP users, but because they feel they identified a situation
where they can make a positive impact.
Best regards
Tim Düsterhus
