Re: Prefixing names of new filter functions with filter_
| From: | Pierre | Date: | Thu, 14 Sep 2006 09:31:15 +0000 |
| Subject: | Re: Prefixing names of new filter functions with filter_ | ||
| References: | 1 | Groups: | php.internals php.pecl.dev |
| Request: | Send a blank email to internals+get-25681@lists.php.net to get a copy of this message | ||
Hello,
On 9/14/06, Dan Scott <denials@gmail.com> 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" matchesfilter_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