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