Hello, Before any further comment, I have to say that I'm more than disappointed to have put so much effort to get a concensus from the PHP developers here and lost it right away because you, alone, thinks that *we* made wrong choices. I cannot accept that any longuer, I do not want to block 5.2 endlessly and this discussion is getting more than annoyed, each time I make 10 steps forwards, you come in and put us back behing the starting blocks.
If you like to drop our choices, please get the approbations of the developers. On 9/25/06, Derick Rethans <[EMAIL PROTECTED]> wrote:
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.
We actually filter input variables and PHP defined variables, we filter data. Filter is a valid choice (and apply to CS). But I really don't care about input_ or filter_. filter_ being the one we (everyone else) choosed, I accept this choice.
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.
The filter type is per se only an argument, even if it is the main one. it brings consistency and flexibility to the developer. You can pass the same array to filter_get and to as element of a filter_get_args array.
> 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).
The flags are considered as the common usage. Any other arguments must use an array. The other way 'round can make sense too in some cases, or not. It is just an arbitrary choice using the current set of filters. My accepted proposal does not have this issue.
> 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.
It is by no mean different. We only do part of the developer job, optionally prefilter the input variables and fetch them from the rigth array. The rest is exactly the same. There is no conceptual difference, only different sources of the data.
> 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.
We as everyone else and me, not you and me.
> 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?
I meant filter_data, sorry for the confusions.
> 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.
Good, we (everyone and you) agree at least one one thing.
> 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.
A scalar is not expected as the *ARRAY* flag has been given. It is really handy and usefull, for all the reasons described in this thread. I will commit my patch tonight. It cleans a lot the code but keeps all the features. No matter what will be the conclusions of this endless discussion, it will be easy to change the code accordingly, if there is an agreement. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
