On 01.07.2021 at 14:15, Pierre Joye wrote:
> Hi Nikita,
>
> On Wed, Jun 30, 2021, 4:32 PM Nikita Popov <nikita....@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 different
>> 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: support
> nightmare
>
> Any image will be broken if a server is not configured smoothly for prod.
> 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 = 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
