Hello, On 9/14/06, Dan Scott <[EMAIL PROTECTED]> wrote:
Hmm. Should we take advantage of the EXPERIMENTAL warning on http://php.net/filter to rename most of the new filter functions to prefix them with filter_ so that we adhere to CODING_STANDARDS (Naming Conventions [2])?Rather than simply prefixing filter_ to the existing functions, I think we can make the function names more consistent with themselves and with precedents in PHP docs and other function names with the following changes: filter_data -- no change input_filters_list -> filter_names input_get_args -> filter_get_variable_array ("variable" matches
filter_get_args, proven to be clear. What do you mean by "will sort alphabetically before filter_get_variable_array"?
terminology in http://php.net/manual/en/language.variables.external.php, array is explicit) input_get -> filter_get_variable (will sort alphabetically before filter_get_variable_array)
filter_get, or filter_get_one. What do you mean by "will sort alphabetically before filter_get_variable_array"?
Oh, and theoretically the INPUT_* constants should get a FILTER_ prefix as well. So I'm throwing that against the wall to see if anything sticks. If there is agreement to the renaming, I'm pretty sure I can whip up a patch for the extension / unit tests / docs to get things back in sync.
I think no harm to rename the functions now, however I'm not sure the CS apply strictly here. You may consider these functions like a ext/standard or a builtin functions. I don't think we should prefix all of builtin functions. --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
