Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115255
To: Pierre Joye <pierre.php@gmail.com>, Nikita Popov <nikita.ppv@gmail.com>
Cc: PHP internals <internals@lists.php.net>
References: <CAF+90c96J7dyq1KsgoPTndM09V=oj46cXm0SxjfkJXiL3TjdHg@mail.gmail.com>
 <CAEZPtU4YCNCtsmZn=8055+=CUoAHXj1V4n_5dx0m7VU_UfivCA@mail.gmail.com>
Message-ID: <07c20336-5911-fc65-e001-3c43a72b6e1c@gmx.de>
Date: Thu, 1 Jul 2021 16:14:29 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <CAEZPtU4YCNCtsmZn=8055+=CUoAHXj1V4n_5dx0m7VU_UfivCA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [VOTE] Deprecations for PHP 8.1
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 01.07.2021 at 14:15, Pierre Joye wrote:

> Hi Nikita,
>
> On Wed, Jun 30, 2021, 4:32 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
>
>> Hi internals,
>>
>> I have opened voting on https://wiki.php.net/rfc/deprecations_php_8_1. =
The
>> vote closes on 2021-07-14.
>>
>> This RFC is a collection of various deprecation suggestions from differ=
ent
>> people. Each deprecation is voted separately, and should be considered =
on
>> its own merit.
>>
>> Most deprecations should be uncontroversial, but there are some more
>> contentious ones as well: See https://externals.io/message/113657 for
>> additional discussion.
>
> I hope the num_points do not pass. However if it does, I would like to
> still reconsider it for the reasons I mentioned in the discussion: suppo=
rt
> nightmare
>
>  Any image will be broken if a server is not configured smoothly for pro=
d.
> Unlike another script, the depreciation is not visible directly in the
> page. Given the amount of usages of these functions out there, I really =
ask
> to reconsider this one. Too much possible hassles for no real gain.

In my opinion, *not* having a signature like

    function imagepolygon(
        GdImage $image,
        array $points,
        int $num_points_or_color,
        ?int $color =3D null
    ): bool {}

and the respective implementation mess, is a gain; not a huge gain, but
still a real gain to me.

And image generation code which relies on display_errors to catch errors
is already broken.  By your argument, we could not even introduce new
warnings.

Anyhow, fixing the deprecated code would be trivial (the RFC shows an
example), and can even be automated, and I consider it not unlikely that
code which runs on PHP 8 has unit-tests and/or static analysis what may
catch this issue early.

Christoph