Hi Rowan,
On Tue, Jan 28, 2014 at 3:13 AM, Rowan Collins <[email protected]>wrote:
>
> IMHO, aliases would not affect readability. Users would understand what
>>
>> word_wrap() and wordwrap()
>> htmlspecialchar and html_special_chars()
>> and so on
>>
>> means.
>>
>
> But they might wonder if there was a difference between them, particularly
> if the aliases are more distinct (e.g. count() vs sizeof()).
>
>
I agree. Completely different name could be pain.
>
> I agree that automatic aliasing would not be good.
>> String and array function names needs more discussion.
>> GD function names may be aliased automatically, for example.
>>
>> We should discuses if we are going to add standard name aliases
>> to module functions or not, perhaps?
>>
>
> Yes, I think per-module / extension is the way to go - as with the pg_*
> functions you mentioned earlier.
>
> It can then be proposed that a certain module be converted to OO (as
> happened with DateTime), another tidied up to have a consistent naming
> structure, and another left alone until more "interesting" changes are
> being made to it.
String and array function alias discussion would be difficult to reach a
consensus.
Let's separate discussion and concentrate module function at first.
We have new function "apache_request/response_headers" and "getallheaders"
in "CLI" server.
const zend_function_entry server_additional_functions[] = {
PHP_FE(cli_set_process_title, arginfo_cli_set_process_title)
PHP_FE(cli_get_process_title, arginfo_cli_get_process_title)
PHP_FE(apache_request_headers, arginfo_no_args)
PHP_FE(apache_response_headers, arginfo_no_args)
PHP_FALIAS(getallheaders, apache_request_headers, arginfo_no_args)
{NULL, NULL, NULL}
};
We should avoid these kind of naming also.
I'll check modules and list candidates in the RFC.
Regards,
--
Yasuo Ohgaki
[email protected]