Re: ext/filter, Final API proposal

Hello, On 9/19/06, Derick Rethans <derick@php.net> wrote:

On Sat, 16 Sep 2006, Pierre wrote: Hello, Given the recent discussion about the filter API in the pecl-dev list (http://news.php.net/php.pecl.dev/4123), I summarize again what I proposed a while back. It is very important to agree on an API now or we will have to remove filter from 5.2.0. This proposal does not reflect what we have now in CVS. The major changes are: - drop filter_data, input_get will use INPUT_DATA just like input_get_args - input_get accepts takes no option or flag by default, only the filter type. If you need options or flags, you pass them and the filter type as array. Consistent and flexible. I think that is a bad idea, and it's also something I disliked in the _get_args() implementation as we'd basically be overloading the parameter then. I would not want that for input_get(), and I think we should also come up with something else for the definition in input_get_args() there as well.

There is no other choices. Unless we add naming argument in php 5.2, we are out of choicses. I also not think a function with five arguments and one of them being mixed is a good thing, it is what we did in the early versions of php, it was and is a mistake. Having an array is just readable, easy to remember and to extend. Everyone here agreed.

I think we should just stick to the old syntax here: input_get(INPUT_GET, 'mystring', FILTER_SANITIZE_STRING, FILTER_FLAG_ENCODE_HIGH|FILTER_FLAG_ENCODE_LOW );

And you have to use an array if you have options, add a fifth argument for the upcoming charset, and a sixth if we need another one? That's insane and confusing, sorry.

In that case INPUT_DATA becomes ugly so I prefer a different function for filtering already existing data in variables (as you're not getting any input as "input_get" refers to).

It is consistent. All function works the same way. The same definition works for both filter_get and filter_get_args. About this extension being more core and being able to do not follow the CS, please convince everyone else here. I really don't care about filter_ or input_. But I really care about API consisitency, code simplicity (internally and in userland). I have a patch ready for this proposal, the code is much more simple and smaller. I thought you will follow other devs oppinion, my bad... --Pierre