Hello,
On 9/19/06, Derick Rethans <[EMAIL PROTECTED]> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
