On Sun, Oct 2, 2022 at 4:10 PM Larry Garfield <la...@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?
