My vote is on StudlyCaps for class method and attribute names. This is
the standard in many OO languages (SmallTalk, C#, Java - as a
parenthetical I don't think that SmallTalks adoption of StudlyCaps (one
of the first I'm aware of) had anything to do with _ rendering), and
while we do not need to mimic other languages, adopting common
conventions is a good thing.

+1 for studlyCaps -- contrast IAmAndi versus nameIsAndi, the chosen
variable name makes all the difference.

Cheers,
Rob.

.------------------------------------------------------------.
| InterJinn Application Framework - http://www.interjinn.com |
:------------------------------------------------------------:
| An application and templating framework for PHP. Boasting |
| a powerful, scalable system for accessing system services |
| such as forms, properties, sessions, and caches. InterJinn |
| also provides an extremely flexible architecture for |
| creating re-usable components quickly and easily. |
`------------------------------------------------------------'

George Schlossnagle wrote:

My vote is on StudlyCaps for class method and attribute names. This is
the standard in many OO languages (SmallTalk, C#, Java - as a
parenthetical I don't think that SmallTalks adoption of StudlyCaps (one
of the first I'm aware of) had anything to do with _ rendering), and
while we do not need to mimic other languages, adopting common
conventions is a good thing.
On the other hand, there are Common Lisp (foo-bar-baz), Python (mostly
foobarbaz) and Ruby (mostly foo_bar_baz).

I'm using double-underscores "__" to make autoloading of "fake packages" possible.
An example with StudlyCaps:
org__phporb__compiler__IdlCompiler

With underscores:
org__phporb__compiler__idl_compiler

I guess the first is better but I can live with the second.

IMHO we shouldn't have exceptions. If the DOM extension (and many others)
must use StudlyCaps (because of W3C specifications), all OO-based extension or
code should use too.
We can live with a CS for procedural and other CS for OOP.

Cristiano Duarte

If the votes already takes place, I vote on studlyCaps as a
recommendation for PHP OO API, because of consistency with the
existing PEAR conventions.

I like underscore_delimited_style, but embracing two different
standards will definitely disgust not a few number of people.

haha, with these suckyCaps we have two different styles for core-php
functions; that's worse and that's what we should care about.

Derick

2nd we choose not to do so as we couldn't show errors and all in original
casing, now we can we decided to use studlyCaps and we agreed upon even in
our CODING_STYLE (and we did whether or not that rule was removed today).

That's bollocks. I put that 'rule' in after the PEAR meeting; it had
NOTHING to do with any discussion on the internals@ list.

Derick

3rd using different naming conventions in procedural and oo code seems to be
a pro from my point of view, too.

What is the perceived advantage here?

Do you type "->" and immediately forgot what follows that?

This really is no argument in the context of PHP (no implicit
binding of functions) or Java (no global functions).

- Sascha

Georg Richter wrote:

How about an additional configure option --with-studly-caps (disabled by
default) and defining some additional aliases?

Ouch... That would render code written from one place unusable on
another server..

Oliver

GB/E/IT d+ s+:+ a-- C++$ UL++++$ P++++ L+++$ E- W++$ N- ?o ?K w--(---)
!O M+$ V- PS+ PE- Y PGP t++ 5-- X+@ R- tv++ b++(+++) DI++++ D+ G++ e+>++
h(*) r y+(?)

How about an additional configure option --with-studly-caps (disabled
by
default) and defining some additional aliases?

When we ought to have it, it must be --withStudylyCaps as well :)

Moriyoshi

Sascha Schumann wrote:

-1 on embracing studlyCaps in the context of PHP itself.

(Note: studlyCaps originated with a OO language, namely
Smalltalk, but it is not pervasive in OO land.  If you don't
believe me, just look at the STL.  You won't find any
uglyCaps over there.)

- Sascha

On the other hand, STL isn't really typical "OO land", but more a
library that uses OO for pragmatic reasons as much as it uses functional
style for pragmatic reasons. It is consistent, though, which is what I
desire most, nonetheless of the final choice.

On Wed, Dec 03, 2003 at 11:23:05PM +0100, Derick Rethans wrote :

Andi,

I'm -1 too because I want PHP being consistently have _ in
method/function names. (Another reason is to see the difference between
core and user code as Ulf pointed out).

Since every man and his cow already gave a vote, I'll do so too and
vote -1 for theCapsStyle in PHP itself. However, I think e.g. the
DOM extension should be left at what the W3C suggested (other
extension my need exceptions too).

I like the initial argument brought up by Mr. Wendel, namely to
easily differentiate between PHP method calls and userland written
method calls.

- Markus (and his cow)

I think you misunderstood what I said. I said that I support underscore
naming, but it should be allowed in extensions which follow a specific
standard such as DOM (W3C), obviously Java connectivity (that's really not
under our control anyway because it depends on how you write your Java code).
Most extensions, such as mysqli, don't fall in this category and should
thus use underscores.

Hope I made myself clearer now.

Yup, and I agree 101% percent with you.

Derick

George Schlossnagle wrote:

PHP's internal function names should use _ to delimit between
words.

[snip]

And this what we should consistently adopt for the naming of PHP's
internal method names.

Why should methods differ from functions in naming? That in itself is
inconsistency...

I'm in favour of naming with underscores, simply because that was the
PHP way until now and it helps readability a lot.

This is not really true. In PHP4 there were very few internal classes,
so there was not much of a standard for naming class methods. In
contrast, PEAR has had a large amount of OO code in it and conforms to
StudlyCaps. The whole user-space/internal differentiator argument is
of course bogus because OOP relies on method overloading, so if you
want to extend the internal classes in your userspace code, you are
forced to adopt underscores as well.

It's hard but not impossible to extend internal classes. The workaround
is to write thin wrappers with the studlyCaps convention which only just
call the methods in their parents like INTERNAL_FUNCTION_PARAM_PASSTHRU.
After then comes the real class that extends the functionality by
extending the wrapper. So if another class extends the latter it does
not have to know that the top into the hierarchy is an internal class
that uses different naming convention. Anyway, this is an way to
workaround, not completely clean but can help.

Andrey

Why should methods differ from functions in naming? That in itself is
inconsistency...

I'm in favour of naming with underscores, simply because that was the
PHP way until now and it helps readability a lot.

This is not really true. In PHP4 there were very few internal classes,
so there was not much of a standard for naming class methods.

Again, why should method naming differ from function naming?

It seems that most of the folks who are siding behind using underscores
aren't very interested in using OO code, while the people who are using
OOP extensively already support StudlyCaps. My opinion may be biased
though.

It is. One of the purest OO languages, Ruby, uses underscores to
separate words in method names (I have to admit though that constants
are named in CamelCase usually.)

It's one of the reasons i prefer Ruby over most OO languages out
there...

Huh? That's awful. Who supports that sort of magic?

That's not much more magic than case-insensitive functions.

--
Regards,
Stefan Walk
<swalk@prp.physik.tu-darmstadt.de