Re: Direction for the Function Renaming Effort

Richard Lynch wrote: > 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... A reasonable fear - I have a reprint of a circa 1965 Cobol book that is quite terrifying! :) > Having two ongoing function names for the same function is also not good for > newbies. Good docs and a translator function should help new users out considerably. Imagine a modified version of highlight_string that expands all C-style functions out to their full names... > 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. I agree that renaming is bad. Aliasing, I do not see to be as much of an issue. Perhaps we should look for similar situations and see what happened - look at Perl - they are now in the process of breaking backwards compat so that they have a chance to fix the odd and twitchy bits. > 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. +1 - we will have a much better idea of what we could be getting into after we actually do some work! > 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. True - however, we should count the oddballs. My guess would put the oddballs at closer to 120 than 20. :) --zak