Hi internals,
One thing that I feel gets lost when discussion is spread over multiple
proposals is the following fact:
Purely syntactical deprecations, such as the recently discussed case of
backticks, but also the already accepted deprecations of the "alternative
array access syntax" and the (real) cast, can be performed automatically
and with perfect reliability.
Given a high-quality migration tool, the cost is running "php-migrate.phar
dir/" and importantly (and this is the point I want to make) this cost is
constant regardless of how many different things get deprecated. For this
kind of tooling, it makes no difference whether it only has to replace the
alternative array access syntax, or whether it also needs to replace
backticks, some obscure variable interpolation syntax, or whatever else we
want it to.
As long as the deprecation is purely syntactical, this kind of migration
tooling is reliable -- this certainly does not apply to all deprecations!
For example, the also recently discussed case of undefined variables is not
something that can be reliably migrated in an automated way (at least not
while producing idiomatic code).
Rather than starting a holy war over every single RFC that contains the
word "deprecation", I think we should take a look at our migration story
and possibly invest some effort into creating a "blessed" tool for this
purpose: One that only performs migrations that are completely safe and
should be runnable without fear of breaking code.
I do realize that there is already quite a bit of existing tooling, things
like Rector, various CS fixers and compatibility scanners, but I don't
think that we have anything that just works out of the box to do what is
safe and no more.
If we provide this kind of tooling, I think that the cost/benefit
calculation on deprecation changes: If we have any syntactic deprecations
at all, then it basically doesn't matter how many different (syntactical)
things get deprecated in one release, the migration cost is always going to
be the same. (This is of course a slightly simplified view, but close
enough.)
Nikita
Rather than starting a holy war over every single RFC that contains the
word "deprecation", I think we should take a look at our migration story
and possibly invest some effort into creating a "blessed" tool for this
purpose: One that only performs migrations that are completely safe and
should be runnable without fear of breaking code.I do realize that there is already quite a bit of existing tooling, things
like Rector, various CS fixers and compatibility scanners, but I don't
think that we have anything that just works out of the box to do what is
safe and no more.
Could I suggest an option for it to point out where other (unsafe) migrations
could/should be done so that we know where to look.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256 https://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: https://www.phcomp.co.uk/Contact.html
#include <std_disclaimer.h
If we provide this kind of tooling, I think that the cost/benefit
calculation on deprecation changes: If we have any syntactic deprecations
at all, then it basically doesn't matter how many different (syntactical)
things get deprecated in one release, the migration cost is always going to
be the same. (This is of course a slightly simplified view, but close
enough.)
A practical example ...
I've just sorted out access to a new clients web hosting and fixed
things so I can actually log into the wordpress admin panel. Since there
has been no access since the previous support person who set up the site
went awall there are a lot of messages to deal with. The first one being
that PHP is out of date so wordpress can't upgrade. THAT is good to see
since I already know that the site will be broken if it HAD simply
updated as has happened on other sites! The question now is just what
process to follow to update without taking the site off-line. This is
not something the sites owner would ever be able to handle hence the
request to help out ...
In the case of wordpress, the next problem is working out just what
plugins are currently active, which ones will work if wordpress is
updated, and which may need to be replaced. But the starting point is
what will happen if I start by switching PHP5.5 to PHP5.6 so that
wordpress can be updated at all. Should I simply move direct to 7.2
which I have other wordpress sites running on and crib sheets to help
fixing the problems I have already tracked.
None of this can be sorted by using tools that fix the raw code. The
only route is via third party upgrades which relate to which version of
PHP is running. IF php was a lot more stable when RUNNING older code
then one COULD simply update the version and then play catch-up with
other updates, but with the current situation, one often has to fix raw
code problems to get the older stable site into a state that the upgrade
process will actually work.
Bottom line ... can I justify a decent price for the time sorting all of
this will take when there is no indication just how long it WILL take,
and then what work will be required in addition to simply removing the
nannying messages from wordpress ...
--
Lester Caine - G8HFL
Contact - https://lsces.uk/wiki/Contact
L.S.Caine Electronic Services - https://lsces.uk
Model Engineers Digital Workshop - https://medw.uk
Rainbow Digital Media - https://rainbowdigitalmedia.uk
Hi internals,
One thing that I feel gets lost when discussion is spread over multiple
proposals is the following fact:Purely syntactical deprecations, such as the recently discussed case of
backticks, but also the already accepted deprecations of the "alternative
array access syntax" and the (real) cast, can be performed automatically
and with perfect reliability.Given a high-quality migration tool, the cost is running "php-migrate.phar
dir/" and importantly (and this is the point I want to make) this cost is
constant regardless of how many different things get deprecated. For this
kind of tooling, it makes no difference whether it only has to replace the
alternative array access syntax, or whether it also needs to replace
backticks, some obscure variable interpolation syntax, or whatever else we
want it to.As long as the deprecation is purely syntactical, this kind of migration
tooling is reliable -- this certainly does not apply to all deprecations!
For example, the also recently discussed case of undefined variables is not
something that can be reliably migrated in an automated way (at least not
while producing idiomatic code).Rather than starting a holy war over every single RFC that contains the
word "deprecation", I think we should take a look at our migration story
and possibly invest some effort into creating a "blessed" tool for this
purpose: One that only performs migrations that are completely safe and
should be runnable without fear of breaking code.I do realize that there is already quite a bit of existing tooling, things
like Rector, various CS fixers and compatibility scanners, but I don't
think that we have anything that just works out of the box to do what is
safe and no more.If we provide this kind of tooling, I think that the cost/benefit
calculation on deprecation changes: If we have any syntactic deprecations
at all, then it basically doesn't matter how many different (syntactical)
things get deprecated in one release, the migration cost is always going to
be the same. (This is of course a slightly simplified view, but close
enough.)
This does not really take 3rd party code into account.
(composer packages, wordpress plugins..)
What I could imagine is to let the package manager (e.g. composer) or
the package distribution portal (e.g. packagist) apply these automated
fixes to legacy packages and provide cleaned-up variations.
An "application developer" should not run clean-up scripts on 3rd
party code, unless this is automated and happens each time the 3rd
party code is updated.
And we should not assume that every 3rd party package author will take
the time to update their package.
Nikita
Purely syntactical deprecations, such as the recently discussed case of
backticks, but also the already accepted deprecations of the "alternative
array access syntax" and the (real) cast, can be performed automatically
and with perfect reliability.
I imagine it would allow immediately crossing off a few points of
confusion such as these casts:
(unset)
(integer)
(boolean)
(double)
(real)