php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
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 Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
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

Add a Patch

Pull Requests

Add a Pull Request

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-2024 The PHP Group
All rights reserved.
Last updated: Thu Apr 25 22:01:29 2024 UTC