Re: Direction for the Function Renaming Effort

At 17:46 7.2. 2001, Richard Lynch wrote the following: -------------------------------------------------------------- >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... Agreed. >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. Agreed. But this could be made part of the "official" coding style. (Very minor relief.) >The more I think about it, the less I like the idea of renaming the core >functions. It will be regretted later. Agreed and disagreed. I have both opinions at the same time, if you don't mind. :) >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. It might be that it's either now or never. I think days of PHP are still to come (in terms of spread), and that if we leave the core as it is for a year or two, we might find out we would have to break havoc 5 times bigger than today. (No, I don't think it'd could be painless.) I don't mind (that much) if we end up leaving strlen and friends as they are, but can we agree that future additions to ext/standard should follow a set of rules or will it stay at the implementors hands? This is not as easy, and there are things that I think _deserve_ to be agreed on (even if we only aggree to disagree): Take the ctype extension as an example. Hartmut originaly named the functions one to one with they're C originals. Then he changed the scheme just in time for them to get in 4.0.4 as ctype_whatever. (This is not to blame him at all.) What do you think they should be named? How is your opinion influenced by your possible knowlege or use of C? Would you think the same if you knew (or didn't know) C? And if you prefer the C names, what about the conflict with is_numeric et. al? I. e.: if we agree that a group of prominent "C-mirror" functions should be frozen, what are we gonna do with new ones? >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. Ok, but then we need a definition of a core function. Is nl2br a core function? Is bindec a core function? Which one do you like more? If you don't want to change either regardless of your preference, do you think that such functions coming in future could follow a set of rules? If so, how would you put it? Cynic