Re: Merging PHPLIB into PEAR

Quoting Paul Meagher <paul@datavore.com>: > Personally, I don't see the big deal if someone wants to call a method like > this $this->empy_cart versus $this->emptyCart. The point is consistency. If every class in PEAR uses the same method naming conventions, then it will be easier for developers to develop with PEAR libraries because it will be easier for them to remember what things are called. It's like coding in Java and PHP and switching back and forth: you can certainly train your mind to do it, but once in a while you'll find yourself putting $ in front of java variables, or having to stop and think about something that's different between the two. And there's no reason for us not to just pick one - which I thought we had done - and stick with it. We lose nothing, and gain consistency. > In the case of PHPLIB it is probably creating alot of unnecessary work, > headache and backward incompatabilities to try to convert to the PEAR > standard. If the DB layer is changing, then there are going to be backwards compatibility problems anyway, and they might end up being more subtle and hard to find. Why not provide scripts to convert users' code to use the new names? Why assume that the API is going to be the same, anyway? If we put our standards and conventions up for discussion every time someone decides to contribute a decent chunk of code to PEAR, we'll never get anywhere. I personally don't want to be spending my time on this same discussion a year from now, or even a month. But what will be, will be. -chuck -- Charles Hagenbuch, <chuck@horde.org> Entropy. It's what's for dinner.