php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Request #57092 Lack of consistency between input_get and input_get_args syntax
Submitted: 2006-06-15 18:36 UTC Modified: 2006-11-09 20:18 UTC
From: skalpa at xoops dot org Assigned: pajoye (profile)
Status: Not a bug Package: filter (PECL)
PHP Version: Irrelevant OS: Irrelevant
Private report: No CVE-ID: None
View Developer Edit
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
Package:
Bug Type:
Summary:
From: skalpa at xoops dot org
New email:
PHP Version: OS:

 

 [2006-06-15 18:36 UTC] skalpa at xoops dot org 
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

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2006-06-22 07:27 UTC] pierre dot php at gmail dot com 
Yes, it is the plan to change input_get. It is actually not possible to mix options and flags for example.
 [2006-08-31 14:44 UTC] pierre dot php at gmail dot com 
In order to bring consistency to the API, the argument order has been change in input_get_args.

input_get accepts an optional array as 3rd argument, when you need to pass both options and flags.

About input_data, you can use either filter_data, or input_get_args.

I like to have first move feedbacks on the API before changing it again. 5.2.0 is in the starting block, that will help.
 [2006-09-16 13:12 UTC] pierre dot php at gmail dot com 
Please read this thread:

http://news.php.net/php.internals/25728
 [2006-11-09 20:18 UTC] ilia at prohost dot org 
no longer relevant.
 
PHP Copyright © 2001-2026 The PHP Group
All rights reserved. 		Last updated: Wed Mar 11 20:00:01 2026 UTC