Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:115223
MIME-Version: 1.0
References: <CAF+90c9crhPpSMcTx-ozGo0LGjNuBU43e8fiK_=PJMU6iTHNmw@mail.gmail.com>
In-Reply-To: <CAF+90c9crhPpSMcTx-ozGo0LGjNuBU43e8fiK_=PJMU6iTHNmw@mail.gmail.com>
Date: Wed, 30 Jun 2021 07:54:19 +0700
Message-ID: <CAEZPtU7eBQDWEDKqbV21DkpHMcTVyMuMBsnT7qbnGjVwc=3nhA@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] [RFC] Deprecations for PHP 8.1
From: pierre.php@gmail.com (Pierre Joye)

Hi Nikita,

Very good list, thank you.

The only one I am totally not sure about is image(filled)polygon
$numpoints. There are really tons of codes out there using it. There
is little to no gain to remove it but create a load of 1st level
support requests to many packages and applications. A deprecation
notice in this case, in a not so well configured php, will break the
image display.

I would rather make a documentation deprecation. Once we move to
namespace and objects for this, it is simple to provide a clean
alternative (addPoint(s), etc).

Best,

On Mon, Mar 22, 2021 at 4:25 PM Nikita Popov <nikita.ppv@gmail.com> wrote:
>
> Hi internals,
>
> It's time for another deprecation RFC:
> https://wiki.php.net/rfc/deprecations_php_8_1
>
> This is a collection of minor deprecations that various people have put
> together over the last ~2 years. This RFC was formerly targeted at PHP 8.0,
> but was delayed to PHP 8.1 to reduce the amount of changes necessary for
> PHP 8.0 compatibility.
>
> As usual, each deprecation will be voted in isolation.
>
> As we're still early in the release cycle, it's still possible to add
> additional deprecation candidates, given reasoning for the deprecation, as
> well as available alternatives.
>
> Of course, if there are compelling technical reasons why something should
> not be deprecated, we can move things into the "Removed from this proposal"
> section, in which case it will serve as documentation why some
> functionality should not deprecated.
>
> Regards,
> Nikita



-- 
Pierre

@pierrejoye | http://www.libgd.org