Re: Direction for the Function Renaming Effort

Zeev Suraski wrote: > I don't particularly like str_tok() kind of functions. > My view is that standard C-like functions should remain with their standard > names, and not added aliases that only add underscores. The reason for > this is simple - the C function names are extremely short, and they don't > only save in the underscores, but in the words themselves. For instance, > if we were to add a human-readable version of strtok(), it should probably > be something like string_tokenize() or str_tokenize(). > If we're adding aliases, let's not limit ourselves to just adding > underscores, but actually try to make them readable... Middle ground: 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()) 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 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. -Ronabop -- Personal: ron@opus1.com, 520-326-6109, http://www.opus1.com/ron/ Work: rchmara@pnsinc.com, 520-546-8993, http://www.pnsinc.com/ The opinions expressed in this email are not necessarily those of myself, my employers, or any of the other little voices in my head.