Re: Adding validate_var_array()/validate_input_array() to which version?

Am 04.08.2016 um 21:29 schrieb Yasuo Ohgaki: > On Thu, Aug 4, 2016 at 8:27 PM, Christian Stadler <stadli@gmx.de> wrote: >> Am 04.08.2016 um 12:10 schrieb Yasuo Ohgaki: >>> On Thu, Aug 4, 2016 at 10:07 AM, Christian Stadler <stadli@gmx.de> wrote: >>>> Am 01.08.2016 um 10:23 schrieb Yasuo Ohgaki: >>> I don't mind adding this feature. It requires an API like >>> validate_get_offending_value(). (The name should be nicer) >>> How many of us are interested in this feature? >> Then this new function should have an offset param. With this I could >> check, if the array has any offending values and then continue with the >> rest ... mmh, now that I think of it, this isn't really necessary. >> >> Uhm, well anyway: I'd suggest, that the ind(ex/ices) should be returned >> rather, than the actual value names. > OK. Thank you. > I'll add this. The reason why I said store "value" is the code. > To get index, it has to store index somewhere or change many lines of code. Actually I've suggested returning indices, because of the resulting userland-code. Actually I could work with both. So you should choose, whatever is better optimized for the codebase and/or userland-code. On the other hand (@Yasuo and all others): What's your opinion about adding options, rather than more and more new params? e. g.: - FILTER_VALIDATE_EXCEPTION_ON_FIRST_INVALID --> $options & 1 == 1 (default, should be a better/shorter name) - FILTER_VALIDATE_RETURN_VALUES --> $options & 2 == 0 (default) - FILTER_VALIDATE_RETURN_INDICES --> $options & 2 == 1 Just a quick&dirty example, so don't nail me on that ^^ Regards, Christian Stadler