Re: Trying to summarize the function naming threads

+1 on this. Assuming that we move ahead with this, I would bet that those of us who want to alias the core functions will have a little less fight left in us after reviewing and correcting each of the 75 or so modules! ;) --zak Zeev wrote: > - 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.