Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:118730
MIME-Version: 1.0
References: <CAGBsUrdri=hXQHy5JnVhpiz51FbnqVBHjrBg9-tj8m=vzfZtzA@mail.gmail.com>
 <0cfb9a7b-1168-42ef-ae1a-bdc72210de43@app.fastmail.com>
In-Reply-To: <0cfb9a7b-1168-42ef-ae1a-bdc72210de43@app.fastmail.com>
Date: Mon, 3 Oct 2022 01:18:23 +0100
Message-ID: <CA+p1FaaDimmXXxfmGYogENvTpKp2qvyYNt4MyJT9HrehiTbXGg@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>
Cc: php internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000e1e21205ea164804"
Subject: Re: [PHP-DEV] Sanitize filters
From: davidgebler@gmail.com (David Gebler)

--000000000000e1e21205ea164804
Content-Type: text/plain; charset="UTF-8"

On Sun, Oct 2, 2022 at 4:10 PM Larry Garfield <larry@garfieldtech.com>
wrote:

> The filter extension has always been a stillborn mess.  Its API is an
> absolute disaster and, as you note, its functionality is unclear at best,
> misleading at worst.  Frankly it's worse than SPL.
>
> I'd be entirely on board with jettisoning the entire thing, but baring
> that, ripping out large swaths of it that are misleading suits me fine.
>
>
The whole thing is seriously grim. Looking at the documentation for
filter_var for example, look at what it says for the third parameter,
$options

>  Associative array of options or bitwise disjunction of flags. If filter
accepts options, flags can be provided in "flags" field of array. For the
"callback" filter, callable type should be passed.

At a glance, I think all the examples mentioned in this thread have better
existing alternatives already in core and could just be deprecated then
removed. But it's worth asking, is that what we're talking about here, or
is there a suggestion of replacing the filter API with a more modern,
object API?

--000000000000e1e21205ea164804--