On 15/11/2021 23:35, php-internals_nos...@adviesenzo.nl wrote:
Either way, in my estimation, handling this deprecation will - again -
require not insignificant dev-time from maintainers to determine the
best course of action for each flagged instance and to implement the
changes, and what with the stagnation in OSS already happening, I wonder
if now is the right time for adding this to their work-load, especially
with the relatively flimsy argumentation for this RFC.
Can you approximate how much time you expect this to take?
Adding #[AllowDynamicProperties] to the top of each class seems like it
is unlikely to be something that would take much time, and will almost
certainly be catered for by automated tooling such as Rector before too
long. Even without such tools, it could be applied by hand to hundreds
of files in under an hour. Do you have a reason this is not the case?
Of course, the downside to this is that by doing so it may cover up
existing bugs that this change is meant to help identify.
A distinction must be drawn between changes that MUST be made to be
compatible, and changes that SHOULD be made because your code is
carrying tech debt.
I would be interested in hearing how much of the workload you are
experiencing falls into each category.
...
To cover the other point which is more subjective:
The inability for certain open source projects to keep up should
absolutely not be a reason for PHP to slow down its development.
While OSS library projects are certainly important to the ecosystem,
they represent a tiny fraction of the code that is written, and are
often constrained by a small number of contributors to work on them,
often times only a single person.
Should millions of other developers be held back because of the weak
foundations of certain OSS projects? I think to do so would be a
collosal mistake.
Yes, that means that some of these projects will not be able to do
what's necessary and will fall into disrepair and be abandoned. I
personally consider that an acceptable loss when compared to all the
benefits these changes bring.
We must look to the future, for every line of PHP code that has ever
been written, it's likely that there will be hundreds if not thousands
of additional lines that will be written in the future, many of which
will by people who have never written a single line of code before, in
any programming language.
For that reason it is essential that PHP's out-the-box experience is
sane and safe(ish) by design, and that means that common-sense defensive
coding mechanisms should be the default, not something that you have to
opt into, even if that means that old code will need to be modified to
be compatible with those measures.
To do otherwise would be entirely unethical.
--
Mark Randall
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
