Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:25770
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 64.233.182.188 as permitted sender)
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=AAll3aV2HWUo+U/i6S3tLdNThpLM8PuBrgW6dsrS9GL3CVgjjkb1IVZGPPCbFJon2NrZzX9c4GPJgBCTwekmdEq3+hewXzQPv2mIT+WxWy2D0QQvZialaRqqDc+n4xK+Ytjoji7opfh03Dwkvbq5+oG+ah0QCpfi2SsP04T5ZW0=
Message-ID: <fe05d1540609191453j1aa1b5fckb498bbfff4439789@mail.gmail.com>
Date: Tue, 19 Sep 2006 23:53:30 +0200
To: "Derick Rethans" <derick@php.net>
Cc: internals@lists.php.net, rasmus@php.net, ilia@prohost.org
In-Reply-To: <Pine.LNX.4.62.0609192317250.3563@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <20060916125431.42e9a5dd@pierre-u64>
	 <Pine.LNX.4.62.0609192317250.3563@localhost>
Subject: Re: [PHP-DEV] ext/filter, Final API proposal
From: pierre.php@gmail.com (Pierre)

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