Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:8783
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <5.1.0.14.2.20040326174333.02253510@127.0.0.1>
Date: Fri, 26 Mar 2004 17:43:53 +0200
To: internals@lists.php.net
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Fwd: Re: [PHP-DEV] studlyCaps conclusion
From: andi@zend.com (Andi Gutmans)

I meant "A bad decision is better than no decision".

>Date: Fri, 26 Mar 2004 17:32:13 +0200
>To: "Wez Furlong" <wez@thebrainroom.com>, <internals@lists.php.net>
>From: Andi Gutmans <andi@zend.com>
>Subject: Re: [PHP-DEV] studlyCaps conclusion
>
>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