I believe we are still dIscussing about the sanitizing filters only. No
doubt the filter API in general should be kept in the core as it provides
functional access to input variables with the filter_input() function. The
filter_input() is the only alternative to accessing superglobal arrays
directly. I prefer to use them rather than userland helpers and facades
which may work differently to each other. If you wanted to get back to
superglobal arrays when coding without a framework in PHP 8.3 I won't
believe in that. The set of the sanitizing filters is not perfect, however;
some filters are great and userful:
FILTER_SANITIZE_EMAIL - helps to clean up typical mess caused by
copy-pasting an email.
FILTER_SANITIZE_URI - similar thing but to URIs.
FILTER_SANITIZE_NUMBER_FLOAT - nice since it provides a flag to control
scientific notation (did you know is_float("1e1") is false,
but is_float(1e1), however, you always get a string from input variables,
and there is no other way to handle this case without weird manipulations
on a string).
The purpose of some filters like FILTER_SANITIZE_STRING is difficult to
get, I agree, but the idea to solve common edge-cases with built-in
high-quality functionality is great, PHP is a language for Web and should
consider web context.
On Mon, Oct 3, 2022 at 8:38 PM David Gebler <davidgeb...@gmail.com> wrote:
> On Mon, Oct 3, 2022 at 11:29 AM Max Semenik <maxsem.w...@gmail.com> wrote:
>
> >
> > Is there a compelling need to have this in the core, as opposed to
> > Composer packages? The ecosystem has changed a lot since the original
> > function was introduced.
> >
>
> I don't know that there is, I suspect the answer is probably not and
> sanitization and validation is probably better left to userland code. The
> only argument I can offer as devil's advocate is that certain validations
> or transformations will be faster in core than in library scripts. I would
> wager the most common implementation of such userland libraries today are
> heavily reliant on preg_* functions so having some fast, low level baseline
> in core for common tasks in this category might still make sense.
>
> While we're on the topic, can I bring up FILTER_SANITIZE_NUMBER_FLOAT? Why
> is the default behaviour of FILTER_SANITIZE_NUMBER_FLOAT the same as
> FILTER_SANITIZE_NUMBER_INT unless you add extra flags to permit fractions?
> Why is the constant name FILTER_SANITIZE_NUMBER_FLOAT but its counterpart
> for validation is FILTER_VALIDATE_FLOAT (no NUMBER_)? Why does validating a
> float return a float but sanitizing a float return a string?
>
> What about FILTER_VALIDATE_EMAIL which is notorious for being next to
> useless?
>
> Seems to me like there could at the very least be a plausible case for some
> better to_float(), to_int(), is_valid_email() etc. type functions in core
> to replace some of the filter API.
>
