<sarcasm> Lets create an engine level option, lets calls it "coding_convention". The default is "studlyCaps".
Consider the following code: $foo->fooBarBaz(); When coding_convention=studlyCaps, the engine will resolve the method thus (psuedo code): if (!method_exists($obj, $methodname)) { $tmp_method_name = convert_to_underscored_name($methodname); if (!method_exists($obj, $tmp_method_name)) { error("undefined method $methodname"); } $methodname = $tmp_method_name; } $obj->$methodname(...) When coding_convention=underscores, the engine will resolve it thus: if (!method_exists($obj, $methodname)) { $tmp_method_name = convert_to_studly_name($methodname); if (!method_exists($obj, $tmp_method_name)) { error("undefined method $methodname"); } $methodname = $tmp_method_name; } $obj->$methodname(...) For the speed concious, there will be a configure option to either remove the coding convention checks completely. This approach will keep allow us to keep whichever coding style we end up deciding on (although I suspect we won't reach a decision until PHP 7), while meanwhile allowing the end user a transparent choice of their preference for PHP methods. </sarcasm> Let's stop arguing about this stuff--we all have MUCH more important things to do with our time. My point of view on this: - The guideline is to stick with studlyCaps for OO extensions for consistency with PEAR. - New OO extensions SHOULD try to follow the guideline, but are not required to (no need to create more work for our limited developer resources). Now, if the authors/maintainers of an OO extension want to change to studlyCaps, let them do so (I have no objection to SQLite OO api being changed), but lets not force people that otherwise have no time and have spent a lot of effort over a long period of time (eg: Georg) to rewrite their extensions. [keep in mind that one of the reasons that mysqli was written the way it is to keep it closer to the native library API; changing that is just re-introducing a nightmare for the maintainer.] I've said my piece; lets get over it and get on with it. --Wez. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php