Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:107500
MIME-Version: 1.0
References: <CAF+90c8yxmT+94XBRBGCtJ7jbSXCrXgS8bxPGAWodwv=23aC3Q@mail.gmail.com>
In-Reply-To: <CAF+90c8yxmT+94XBRBGCtJ7jbSXCrXgS8bxPGAWodwv=23aC3Q@mail.gmail.com>
Date: Fri, 11 Oct 2019 13:48:50 +0200
Message-ID: <CAH0Uv3F-CPmUTu0r2gaYsuM9w=9DX7HoSMAT-PuXoTzbkscyzw@mail.gmail.com>
To: Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [PHP-DEV] Migration tooling and the cumulative cost of purely
 syntactical deprecations
From: andreas@dqxtech.net (Andreas Hennings)

On Fri, 11 Oct 2019 at 12:25, Nikita Popov <nikita.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