RE: [PHP-DEV] Re: [PHP-CVS] cvs: php-src / CODING_STANDARDS
| From: | Lukas Smith | 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