Description:
------------
Greetings everybody and thanks for your work.

I've been closely checking the filter extension dev lately as it's one I had been expecting with much enthusiasm. 
I've started to work on a PHP port to ensure the users of my CMS using a < 5.2 version will be able to benefit from it and noticed a few inconsistencies between the input_get() and pierre-alain's input_get_args() that I think you may want to look at.

Here are my ideas:
1) The parameters order between input_get() and input_get_args() is inverted. In input_get(), the 1st parameter defines the source (well, as you called it "type"), while in input_get_args() it now is in 2nd position. I think it would be more obvious for most users to keep the "type" parameter in the 1st position on both functions (by inverting the "type" and "definition" params order in input_get_args).

2) The way input_get_args() allows to specify a custom "data" array is ok for me, but again it may not be obvious for the average PHP user. Also, the way it is actually done maked this feature available in input_get_args() but not in input_get() which only allows INPUT_XXX constants.
Here I think it would be more in the "PHP spirit" to define the "type" parameter as "mixed" (if possible, in both functions in fact).

Thus, we'd have this:
mixed input_get_args( mixed type, array definition )
mixed input_get(mixed type, string variable_name [, int filter],.... )

Giving "type" the possibility to be:
- A constant representing one of the superglobals array
- An array (to get the actual INPUT_DATA behavior)
- A string to be parsed using parse_str() (I dont really see the use of this, but I think I've seen something like this in your source comments, so why not)

Thanks for your time

Skalpa Keo