Migration tooling and the cumulative cost of purely syntactical deprecations

  107494
October 11, 2019 10:25 nikita.ppv@gmail.com (Nikita Popov)
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
  107495
October 11, 2019 10:30 addw@phcomp.co.uk (Alain D D Williams)
On Fri, Oct 11, 2019 at 12:25:11PM +0200, Nikita Popov wrote:

> 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
  107496
October 11, 2019 11:01 lester@lsces.uk (Lester Caine)
On 11/10/2019 11:25, Nikita Popov wrote:
> 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
  107500
October 11, 2019 11:48 andreas@dqxtech.net (Andreas Hennings)
On Fri, 11 Oct 2019 at 12:25, Nikita Popov ppv@gmail.com> wrote:
> > 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
  107511
October 11, 2019 15:14 marandall@php.net (Mark Randall)
On 11/10/2019 11:25, Nikita Popov wrote:
> 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)