Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:8781
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <5.1.0.14.2.20040326172733.01734578@127.0.0.1>
Date: Fri, 26 Mar 2004 17:32:13 +0200
To: "Wez Furlong" <wez@thebrainroom.com>,<internals@lists.php.net>
In-Reply-To: <00c201c41343$32eb8950$8a02a8c0@tron>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] studlyCaps conclusion
From: andi@zend.com (Andi Gutmans)
References: <00c201c41343$32eb8950$8a02a8c0@tron>

I pretty much agree with Wez. A bad decision is worse than no decision :)
The way I see it, studlyCaps has been in the CODING_STANDARDS *and* 
precisely because people and PEAR use them for method names we should go 
with studlyCaps. It would suck to have user-land and internal methods look 
differently. Personally I think it makes sense to keep underscores for 
functions and I see no problem with them differing from methods as I 
usually use underscores for C code and studlyCaps for C++ code :)
We should go with studlyCaps according to CODING_STANDARDS for all 
extensions. If some extension writer refuses (such as George) then so be it 
and we leave it the way it is (although I would ask him to reconsider for 
the long term good of PHP).

Andi


At 03:01 PM 3/26/2004 +0000, Wez Furlong wrote:
><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