Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114036
MIME-Version: 1.0
References: <CAF+90c9crhPpSMcTx-ozGo0LGjNuBU43e8fiK_=PJMU6iTHNmw@mail.gmail.com>
 <7960f1c9-2f72-f923-47db-91dbc0a99b5a@gmx.de>
In-Reply-To: <7960f1c9-2f72-f923-47db-91dbc0a99b5a@gmx.de>
Date: Mon, 12 Apr 2021 15:11:51 +0200
Message-ID: <CAF+90c_-Edawjm5-9u24MkaKDj8HXjOdOGKkSmekqHhpwNZpjg@mail.gmail.com>
To: "Christoph M. Becker" <cmbecker69@gmx.de>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000c16fc605bfc642fc"
Subject: Re: [RFC] Deprecations for PHP 8.1
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000c16fc605bfc642fc
Content-Type: text/plain; charset="UTF-8"

On Fri, Mar 26, 2021 at 3:41 PM Christoph M. Becker <cmbecker69@gmx.de>
wrote:

> On 22.03.2021 at 10:24, Nikita Popov wrote:
>
> > It's time for another deprecation RFC:
> > https://wiki.php.net/rfc/deprecations_php_8_1
> >
> > 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.
>
> I'd like to propose the deprecation of odbc_result_all()[1].  My main
> motivation for getting rid of this function is to reduce unnecessary
> complexity in the ODBC extension.  I doubt that this function is used
> (often) in production code, and even for quick experiments/tests it is
> unlikely to be helpful.  For those needing it, it shouldn't be hard to
> implement it in PHP.
>
> [1] <https://www.php.net/manual/en/function.odbc-result-all.php>
>

I'm on board with deprecating odbc_result_all(). This is pretty much the
archetype of old school PHP -- make a query and dump the result right into
an HTML table... Escaping? Who needs that!

Nikita

--000000000000c16fc605bfc642fc--