Re: ext/filter, Final API proposal
| From: | Pierre | Date: | Sat, 16 Sep 2006 15:11:10 +0000 |
| Subject: | Re: ext/filter, Final API proposal | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-25733@lists.php.net to get a copy of this message | ||
Hello,
On 9/16/06, Christian Schneider <cschneid@cschneid.com> wrote:
Pierre wrote: It always returns an array when FILTER_FLAG_ARRAY is given. Even when the input value was a scalar. It spares yet another is_array/isset test. And it accepts only scalar by default or when FILTER_FLAG_SCALAR is given. Makes sense but the example shows:Again, this proposal is not based on the current neither on the examples in the manual (I did not check them recently, there is maybe mistakes).
a) This is a documentation bug b) FILTER_FLAG_ARRAY is 'inherited' from the previous arg ('component') c) The values are always returned as array My favourite one being a) :-)This is what this proposal says too, so I consider that you agree :)
It uses INPUT_REQUEST (which is not yet implemented, and will not be for 5.2.0). One should rely only on the constants not their values :) I agree wholeheartedly but I think it would be nice to have INPUT_REQUEST for 5.2.0 already. Or are you advising people to useSadly no, it will not be in 5.2.0. We do not have the time, the resources and the required tests to implement it before 5.2.0.
$myinputs = input_get_args(INPUT_GET, $args, $data) + input_get_args(INPUT_POST, $args, $data) [ + ... ]; as work-around for now? Just wondering...It will be array_merge(G,P,C,S) then, but this is not the goal of this thread :-)
However, the point was about the API changes (signature, way to call them, etc...). I suppose you like it? Yes, the API looks great as far as I can tell.Danke! --Pierre