RE: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS

From: Date: Wed, 03 Dec 2003 16:00:15 +0000
Subject: RE: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
References: 1  Groups: php.internals 
Request: Send a blank email to internals+get-6111@lists.php.net to get a copy of this message
> 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

« previous php.internals (#6111) next »