Re: Direction for the Function Renaming Effort

Ron Chmara wrote: [snip] > If we have a standard PHP naming space, and create "convenience versions" > and or "cross language versions", we can have, for one function: > strtok() > str_tok() > string_tokenize() > string_token() > tok_str() > tokenize_a_string() > ....and even (for completeness' sake) > array_functions_which_split_a_string_token() > (as compared to array_functions_which_split_a_string_explode()) For the functions that are C/Perl/Shell synonyms, I feel that we should only have 1 alias for them. > If we start encouraging the use of 'my_' (my_str_tok) to help > preserve the users's name space, we should have less issues later > with running out of namespace room. (I realize this is documentation, > not core programming, but I thought I'd float it out there... for > the record, I don't do this....yet. :-) I may start soon, > considering these discussions....) I have always hated my... and I don't know why. I have a silly little hack to get around the problem. (http://www.zend.com/codex.php?id=183&single=1) > I think the renaming goal is not to *limit* the possibilities, as much > as it is to provide for PHP's users to have a consistant naming space, > a consistant way of usage, so the user isn't *guessing* at the naming > style. (Is it named the same way as the C function? Does it work the > same? Is it named the same as the Perl function? Does it work the same?) This > consistancy makes documentation and first-language-adoption easier, but > (as Zeev rightly points out) functions which mirror outside languages > can be _easier_ to use if they have a PHP name that is similar to the > outside name, so a C programmer can use their macros, their mental > habits, effectively, a Perl programmer can expect chop() (yes, I'm > picking on chop()) to work the same, etc. > > So we really have more options than "rename" or "don't rename". It > just has to be done intelligently, so it fits for both users who > use Perl, C, and PHP, as well as users who are learning PHP as their > first language, and will reap greater benefits from all functions > being uniformly named. > > When do I think it gets absurd? When the naming of functions creates > more human keystrokes than needed, or when the shortcut names start getting > into competition (somebody used read()) when there isn't a consistant, > universal, usage, or when each function has 5 (arbitrary number) > aliases. Well summed up - we are trying to make the language more usable. This should be the overriding constraint that we work within. --zak