Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:6111
Return-Path: <smith@backendmedia.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 31920 invoked by uid 1010); 3 Dec 2003 16:01:46 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 31896 invoked from network); 3 Dec 2003 16:01:46 -0000
Received: from unknown (HELO mail.dybnet.de) (195.75.116.242)
  by pb1.pair.com with SMTP; 3 Dec 2003 16:01:46 -0000
Received: (qmail 25085 invoked by uid 508); 3 Dec 2003 16:02:42 -0000
Received: from unknown (HELO vandal) (vandal@212.202.39.121)
  by www.dybnet.de with RC4-MD5 encrypted SMTP; 3 Dec 2003 16:02:42 -0000
To: "'Sascha Schumann'" <sascha@schumann.cx>
Cc: <internals@lists.php.net>
Date: Wed, 3 Dec 2003 17:00:15 +0100
Organization: BackendMedia GbR
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook, Build 11.0.5510
In-Reply-To: <Pine.LNX.4.58.0312031649230.13271@fragrance>
Thread-Index: AcO5tZ6+Z+fJMpWcTCq9e7+NHLU2UAAAEczQ
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165
Subject: RE: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
From: smith@backendmedia.com ("Lukas Smith")
Message-ID: <php.internals-6111@news.php.net>
References: <Pine.LNX.4.58.0312031649230.13271@fragrance>

> From: Sascha Schumann [mailto:sascha@schumann.cx]
> Sent: Wednesday, December 03, 2003 4:53 PM
> 
> On Wed, 3 Dec 2003, Lukas Smith wrote:
> 
> > > From: Sascha Schumann [mailto:sascha@schumann.cx]
> > > Sent: Wednesday, December 03, 2003 4:39 PM
> >
> > > > The fact that PEAR has a serious problem extending non studlyCap
> objects
> > > is
> > > > probably something a lot of people in PHP core don't care about.
> > >
> > >     Please elaborate.
> >
> > Well if I extend a class that doesnt use studlyCaps, yet the PEAR CS
> > requires that I use studlyCaps, then I have a problem. Essentially I can
> > only wrap and not extend. I guess you can say this is our problem
> however,
> > since we could also choose to loosen our CS to allow underscores.
> 
>     Agreed.
> 
> > I don't
> > feel that having to ways in there is the way to go. I prefer to stay
> with
> > one which results in the fewest breaks with the outside world.
> 
>     You apparently live in an alternative "outside world".  In
>     mine, there are 99% C bindings where studlyCaps virtually do
>     not exist.

And here is the other difference in opinion:
To me procedural APIs bound to an OO API "break" their heritage and so I
don't have a problem of going to studlyCaps. Actually I think it is even an
advantage because it makes me differentiate procedural code from OO code
more easily. But now we are getting into aesthetics again :-)

So it goes .. I don't feel I have anything to add beyond what I have said so
far and I hope I haven't wasted peoples time (even if the only value was to
reassure the opinion that studlyCaps is not for PHP).

Regards,
Lukas