Re: Direction for the Function Renaming Effort

I'm a little concerned that we don't get carried away with aliases and end up with a COBOL-like situation where ever decent variable name is a keyword of the language... Having two ongoing function names for the same function is also not good for newbies. They see one script with strtok, and another with string_tokenize and think there's twice as much to learn. The more I think about it, the less I like the idea of renaming the core functions. It will be regretted later. Since everybody seems to agree that enforcing consistency on the extension's names, perhaps we should start there and let the core alone until there's more time for reflection. Getting the extensions to be consistent would probably make the hatful of core function "oddities" much less of an issue. Memorizing ~20 function names that are funky is not a Big Deal. Also, as core functions, it's perhaps better that they are "odd" Newbies will know (perhaps subconciously) that they are somehow different and pervasive throughout PHP installations. -- Visit the Zend Store at http://www.zend.com/store/ Wanna help me out? Like Music? Buy a CD: http://l-i-e.com/artists.htm Volunteer a little time: http://chatmusic.com/volunteer.htm ----- Original Message ----- From: Cynic <cynic@mail.cz> To: André Langhorst <waldschrott@php.net>; Zeev Suraski <zeev@zend.com>; PHP Quality Assurance <php-qa@lists.php.net> Sent: Wednesday, February 07, 2001 6:33 AM Subject: Re: [PHP-QA] Direction for the Function Renaming Effort (Prefix: Again, what is the impact--performace-wise--of many PHP_FALIAS()es? Is something like --enable-strict-names / --enable-strict-names-only viable?) At 12:40 7.2. 2001, André Langhorst wrote the following: -------------------------------------------------------------- >[+1] for creating a list with string functions which should *NOT* aliased and renamed I'm afraid this would be shooting the effort in the leg. We should think the opposite way. >str_ group: >str_implode -- Join array elements with a string >str_join -- Join array elements with a string >str_levenshtein -- Calculate Levenshtein distance between two strings >str_locale_conv -- Get numeric formatting information >str_md5 -- Calculate the md5 hash of a string >str_Metaphone -- Calculate the metaphone key of a string >str_nl2br -- Converts newlines to HTML line breaks what about str_nlbr (like dechex) or str_nltobr (like strtolower) or even str_nl_to_br? (I don't like this one). this should be resolved too. This is a sub-issue, but from my POV it's very important to have a scheme for this too. >str_parse -- Parses the string into variables >str_quoted_printable_decode -- Convert a quoted-printable string to an 8 bit string >str_quote_meta -- Quote meta characters >str_set_locale -- Set locale information >str_similar_text -- Calculate the similarity between two strings > >exceptions: >print -- Output a string >printf -- Output a formatted string >sscanf -- Parses input from a string according to a format ok, but then again, I can understand if someone feels it should be str_print. On the other hand, you can print() a boolean or a double... var_print()? You can print a constant... So I'd stick with just print(). >str group >strrpos -- Find position of last occurrence of a char in a string >strspn -- Find length of initial segment matching mask >strstr -- Find first occurrence of a string >strtok -- Tokenize string what's wrong with str_rpos? >dunno, maybe exceptions?: >Ord -- Return ASCII value of character >rtrim -- Remove trailing whitespace. str_rtrim might look strange or crippled, but that is the case with most of the functions. Virtually everybody will have their favorite function, and they'll feel "offended" if it changes -- because "booo, strtok's been strtok for years in C, what's that str_tok shit?" ____________________________________________________________ Cynic: A member of a group of ancient Greek philosophers who taught that virtue constitutes happiness and that self control is the essential part of virtue. cynic@mail.cz -- PHP Quality Assurance Mailing List <http://www.php.net/> To unsubscribe, e-mail: php-qa-unsubscribe@lists.php.net For additional commands, e-mail: php-qa-help@lists.php.net To contact the list administrators, e-mail: php-list-admin@lists.php.net