Quoting Paul Meagher <[EMAIL PROTECTED]>:

> 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.


Charles Hagenbuch, <[EMAIL PROTECTED]>
Entropy. It's what's for dinner.

PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]

Reply via email to