The problem is this creates a difference with the PEAR classes and PEAR standards.
I agree that on the whole using underscores is a better method, its my preference as well. But PEAR already made the decision to go with studlyCaps, and we should follow in suite (as they are the largest collection of OO classes for PHP, and tightly integrated with PHP). Its also important to consider that PEAR needs to extend internal classes and provide extra information (like the Exception class). We don't want them to have to alias every method to the compatible version for their needs. You also have the fact that most specified (standard) OO apis follow the studlyCaps notation (chregu mentioned DOM as an example, there are others). Conforming to these (or coming close as possible) is a good thing. Whether studlyCaps are nice or not is imho really irrellevant at this point. Its about following a naming standard, and the decision has already been made by PEAR. -Sterling On Thu, 2003-09-04 at 17:23, Derick Rethans wrote: > On Thu, 4 Sep 2003, Marcus Börger wrote: > > > As the only consequence i think we should remove that part 6 from our CS. > > let's replace it with this: > > [6] Method names follow the same naming style as normal > functions like "mysql_connect". > > Good: > 'connect()' > 'get_data()' > 'build_some_widget()' > > Bad: > 'get_Data()' > 'buildSomeWidget()' > 'getI()' > > Derick > > > -- > "Interpreting what the GPL actually means is a job best left to those > that read the future by examining animal entrails." > ------------------------------------------------------------------------- > Derick Rethans http://derickrethans.nl/ > International PHP Magazine http://php-mag.net/ > ------------------------------------------------------------------------- -- We all agree on the necessity of compromise. We just can't agree on when it's necessary to compromise. - Larry Wall -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
