Trying to summarize the function naming threads

I hope I won't wake up tomorrow and see that this has spawned a new endless thread, but at this risk, I'll try to summarize our status (from my point of view, no doubt) and then say what I think what should/shouldn't be done. - I think we all realize that we don't have a consensus about the ultimate solution to the problem. Many different people support many different solutions. - Some people (like me), don't even agree with the above statement, because that statement takes it for granted that there is a problem. In my opinion, this is very much an open issue, and considering the fact that I haven't seen too many complaints, I'll be very cautious as to perform 'corrective actions'. - I don't think that PHP is 'before the big break', at least not popularity-wise. It's definitely in it right now, perhaps even after it. With almost 20% of the Web being powered by various versions of PHP, and with competitors such as Microsoft and Sun, you can only go so far. I don't think we can or should allow ourselves to perform revolutionary downwards incompatible changes such as these. Any solution we come up with should allow the huge existing code base to go on running without having to perform wide-scale code updates. As for what I think should/shouldn't be done. My opinion about function renaming was more or less consistent along the years. I personally don't consider the 'standard' function names, that are named after their C counterparts, to be problematic. Sure, they may be awkward to some people, but I'm really not sure if there are more people who aren't familiar with other languages using PHP than there are people who are. At any rate, I think that the decision with these functions was done several years ago, and given my last point above (PHP is pretty much beyond the point of no return), I don't think we're in a position to change that. As for library functions, my approach is apparent in the MySQL module. I kept old PHP/FI 2.0 aliases, but they're not documented. So, if the function is already a legacy function, and everybody and their dog is using it, changing its name is not an option. Adding an alias and removing documentation for the old function is. There are some cases in which there's a family of functions that *should* have a consistent naming convention but doesn't. In such extreme cases (which I think are fairly rare, one example being the binhex and hex2bin family), my opinion is that we should decide upon a consistent naming convention, and apply it. I'm not sure whether we should keep the old names or not, as unlike library functions, which have (or should have) a unique prefix that users aren't less likely to use (essentially, a namespace with _ being the separator), such library functions do not, and they clutter the namespace badly. I don't feel strongly about this though, it may be ok to keep them. All in all, I think we should take it one function at a time, and address each case (which can be an entire library or a function family) on its own. The de-facto problem is not that big (no real complaints from users), and doesn't call for intrusive actions. Zeev -- Zeev Suraski <zeev@zend.com> CTO & co-founder, Zend Technologies Ltd. http://www.zend.com/