Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107494
MIME-Version: 1.0
Date: Fri, 11 Oct 2019 12:25:11 +0200
Message-ID: <CAF+90c8yxmT+94XBRBGCtJ7jbSXCrXgS8bxPGAWodwv=23aC3Q@mail.gmail.com>
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000d6843a05949fef9a"
Subject: Migration tooling and the cumulative cost of purely syntactical deprecations
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000d6843a05949fef9a
Content-Type: text/plain; charset="UTF-8"

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

--000000000000d6843a05949fef9a--