On Friday 26 March 2004 16:54, Andi Gutmans wrote:
> At 04:50 PM 3/26/2004 +0100, Edin Kadribasic wrote:
> >On Friday 26 March 2004 16:43, Andi Gutmans wrote:
> > > I meant "A bad decision is better than no decision".
> >
> >So this bad decision is to have a standard that everybody is free to
> > i
At 04:50 PM 3/26/2004 +0100, Edin Kadribasic wrote:
On Friday 26 March 2004 16:43, Andi Gutmans wrote:
> I meant "A bad decision is better than no decision".
So this bad decision is to have a standard that everybody is free to ignore?
It means that we change whatever extensions aren't studlyCaps to
On Friday 26 March 2004 16:43, Andi Gutmans wrote:
> I meant "A bad decision is better than no decision".
So this bad decision is to have a standard that everybody is free to ignore?
Edin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I meant "A bad decision is better than no decision".
Date: Fri, 26 Mar 2004 17:32:13 +0200
To: "Wez Furlong" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
From: Andi Gutmans <[EMAIL PROTECTED]>
Subject: Re: [PHP-DEV] studlyCaps conclusion
I pretty much agree wit
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
differ
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
