On Thu, 21 Sep 2006, Pierre wrote: > Before any further comment, we agreed on the "filter" prefix. We have > to stick to it. I also think we should respect other developers > choices. > > As you said, filter is more than a simple extension, its design choice > should not be up to only one or two persons. My proposal has been > approved by many developers in this thread and in pecl-dev.
There were comments as to follow CS for the function names, but that doesn't mean that we can't pick the obvious choice of renaming the extension to "input" instead of "filter". As the functions deal with getting input through a filter, there is nothing wrong with using input_* for the function names and "input" as extension name. > On 9/20/06, Derick Rethans <[EMAIL PROTECTED]> wrote: > > On Tue, 19 Sep 2006, Pierre wrote: > > > > > On 9/19/06, Derick Rethans <[EMAIL PROTECTED]> wrote: > > > > On Sat, 16 Sep 2006, Pierre wrote: > > > > > > > > > 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. > > > > Well, you're still doing the same, but now with the parameter that also > > contains the filter. This is fundamentally different compared to the > > previous API, because both the flags and the options *modify* a filter, > > and both of them are not required. > > I know that both modify a filter. And I do think that array make the > code way more readable and easier to extend. An array for the options and flags - yes. But mixing the filter itself with the option and flags array doesn't make sense as they are two *different* things that the function accepts. > > When I was first implementing this stuff I thought that it was > > best to always use an array to specify both options and flags as 4th > > parameter. However, there is only one filter (validate_int) that > > currently uses the options (min_range and max_range); and I found that > > having to use an array for all other filters just because of > > validate_int was a bad idea, as it unnecessarily bloats calling > > filters with funky array() syntax. Hence the status quo where you only > > have to use an array if you want to use options besides flags at well. > > More filters will use option (like IP for examples, or url, mails). An > array allows a clear and extendable signature. I don't think anyone > here can affirm that no other filter will use more options, flags or > arguments. The goal is to create an API that we will not have to break > in a near future, especially not because we added more filters. An > array gives us this security. You don't have to break anything here in the future. There are many filters now which only take flags. Requiring to have to use array( 'flags' => ... ) in that case is annoying and unnecesary. Ofcourse, the array syntax *should* be supported as as well because some filters will also require options. Then you will not have to break anything and you still allow the easier syntax in case a filter only has flags (or when you only need to use flags for a filter). [snip] > > > > 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. > > > > Actually, it's less consistent *and* it would require another parameter > > to the functions, while you just suggested that you disliked more > > parameters. Again, it's also fundamentally two different things: > > - request input data > > - existing variables > > Therefore there should be two sets of functions, one of the classes with > > both a single filter specification and one with a filter specification > > array. > > It makes no difference to filter a variable or input data. Having both > modes in one function allows easy integration of the filter API into a > more generic API. Ofcourse it makes s difference. To filter an already existing variable with data is conceptually different from receiving variable data by means of an input source and variable name. Because it is conceptually different we shouldn't try to stick those two different things into one function's API. > We also agreed here on this choice. "We" didn't agree on this at all otherwise I wouldn't have made a comment about it. > Droping custom functions to filter variables (from script, not input > data) has been requested and approved. I think it is a good thing. What? You propose to drop support for callbacks here? And who approved that and where was it requested? > >From the mail about how FLAG_ARRAY should work: > > > > On Tue, 19 Sep 2006, Pierre wrote: > > > > > On 9/19/06, Derick Rethans <[EMAIL PROTECTED]> wrote: > > > > I would not expect that... I thought the FLAG would just mean that > > > > it would iterate over a whole array and allow it. I think that we > > > > should add a second flag called "FORCE_ARRAY" or something instead. > > > > > > The flag allows arrays and always returns an array. It is obvious > > > > No it isn't obvious at all. Look at this example: > > > > <?php > > $varSpecs = array( > > 'varName' => array( 'filter' => 'string', 'flags' => > > FILTER_FLAG_ARRAY ) > > ); > > > > $data = array( 'varName' => 42 ); > > > > $filteredData = input_filter_args( $data, $varSpecs ); > > ?> > > > > Because the variable 'varName' has the FILTER_FLAG_ARRAY you say that it > > should make an array out of this, resulting in the data: > > > > $filterData = array( 'varName' => array( 42 ) ); > > > > Unless you want to ignore this flag for filtering already existing > > variables which makes things inconsistent again. > > I do not understand what you mean here. > > Let me explain it again, if the flag is not set and the input is an > array, it returns false (validation fails). Yes, that is fine. > If it is present, you are > sure to get an array in return, even if the variable was a scalar. And this is not. We shouldn't convert a scalar to an array, as we're then basically mangling data. Instead we should return false just like in the case where an array is submitted and a scalar is expected. regards, Derick -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
