Re: ext/filter, Final API proposal

Hello, On 9/16/06, Christian Schneider <cschneid@cschneid.com> wrote:

Pierre wrote: Proposal: ********** I. Availalbe functions: ------------------- * input_get Gets variable from outside PHP or from a userland variable and optionally filters it using one filter and its options or flags. It accepts only scalar by default, array can be returned using ALLOW_ARRAY. Looks good. * input_get_args Gets multiple variables from outside PHP or from a userland variable and optionally filters them using different filters and options/flags. It accepts only scalar by default, array can be returned using ALLOW_ARRAY. The current documentation page shows an example where all return values are an array: array(6) { ["product_id"]=> array(1) {

     [0]=>
     string(17) "libgd%3Cscript%3E"

} ... I would prefer if it would return array(6) { ["product_id"]=>

     string(17) "libgd%3Cscript%3E"

... unless FILTER_FLAG_ARRAY is given in which case it should behave like before. This would make it easier to use the filtered values IMHO.

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.

II input_get

II.1 without options or flags ?mystring=<b>bold</b> input_get(INPUT_POST, 'mystring', FILTER_SANITIZE_SPECIAL_CHARS); The documentation mentions 99 as $_REQUEST for input type right now. I'd prefer to be able to say INPUT_GET | INPUT_POST to get values from a combination of sources. Or at least have INPUT_REQUEST as constant definition instead of 99.

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 :) However, the point was about the API changes (signature, way to call them, etc...). I suppose you like it? --Pierre