# StudlyCaps

- Thread: https://externals.io/message/6139
- Original archive: https://news-web.php.net/php.internals/6139
- Started by Andi Gutmans on 2003-12-03T20:51:40+00:00
- Messages: 43
- Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/6139.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #6139 — Andi Gutmans — 2003-12-03T20:51:40+00:00

URL: https://externals.io/message/6139#6139

Hey,

I think we should come to closure on this discussion because it's becoming 
hard to catch up with.
I'd like to finalize this issue for PHP (the C part) so that we can release 
Beta 3. I think what PEAR does is really up to the PEAR dev team (although 
I think it would be nice for them to be consistent with PHP itself).
The facts are the following:
a) Existing PHP functions use underscores.
b) Some external object models such as Java use StudlyCaps.

The immediate decision we have to make is if PHP's OOP functionality (class 
names and method names) use underscores or studly caps.
I think for (b) 
(interfacing with external object models) the answer is obvious. Do what 
you need to do to expose the external object model, and thus use StudlyCaps 
where applicable. That's kind of obvious IMO. If the external object model 
has underscores then use that.

However, I think what we do with PHP's object model is not that obvious. 
Although I'm quite indifferent to these when I program (I usually use the 
most popular method with the language I'm using) I think there are two 
advantages for using underscores:
a) functions already use them thus we are consistent across the board 
(something we historically don't excel in).
b) StudlyCaps doesn't know how to deal with one character words such as 
IAmAndi. which would be something like i_am_andi in underscores. You often 
find yourself having to do two capitol letters one after another and it 
ruins the whole thing. The same thing happens with acronyms, for example, 
PHPObject (no differentiation between PHP and Object).

I think that even if some OOP developers prefer the studly caps, using 
underscores might even have an advantage of differentiating between PHP 
methods and the user's methods.
Let's not turn this into a religious war. I think everyone here understands 
the pros/cons. Let's try and reach a decision quickly and make sure we 
adopt it, because indecision is worse than making the wrong decision :)

I apologize for the long letter. Please don't copy me :)
Andi

---

## #6140 — George Schlossnagle — 2003-12-03T20:58:02+00:00

URL: https://externals.io/message/6139#6140 · In reply to: #6139

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.

---

## #6142 — Robert Cummings — 2003-12-03T21:44:26+00:00

URL: https://externals.io/message/6139#6142 · In reply to: #6140

> 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.          |
`------------------------------------------------------------'

---

## #6143 — Moriyoshi Koizumi — 2003-12-03T21:49:54+00:00

URL: https://externals.io/message/6139#6143 · In reply to: #6139

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.
Neither Readability nor familiarity does matter here.

Moriyoshi

---

## #6144 — Marcus Boerger — 2003-12-03T21:51:51+00:00

URL: https://externals.io/message/6139#6144 · In reply to: #6139

Hello Andi,

i am pro studlyCaps.
1st it eases PEAR development towards php5.
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).
3rd using different naming conventions in procedural and oo code seems to be
a pro from my point of view, too.

-- 
Best regards,
 Marcus                            mailto:helly@php.net

---

## #6145 — Pierre-Alain Joye — 2003-12-03T21:59:19+00:00

URL: https://externals.io/message/6139#6145 · In reply to: #6139

+1 on studlyCaps

pierre

---

## #6146 — Derick Rethans — 2003-12-03T22:02:30+00:00

URL: https://externals.io/message/6139#6146 · In reply to: #6143

> 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

---

## #6147 — Derick Rethans — 2003-12-03T22:03:47+00:00

URL: https://externals.io/message/6139#6147 · In reply to: #6144

> 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

---

## #6157 — mfischer@gjat.josefine@Markus Fischer — 2003-12-03T22:10:37+00:00

URL: https://externals.io/message/6139#6157 · In reply to: #6152

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)

---

## #6149 — Georg Richter — 2003-12-03T22:14:25+00:00

URL: https://externals.io/message/6139#6149 · In reply to: #6139

I'm -1.

And for ext/mysqli which supports OO, studlyCaps would make life harder, to 
migrate "old" php4 scripts to PHP5 and ext/mysqli.

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

Georg

---

## #6148 — Michael Walter — 2003-12-03T22:14:30+00:00

URL: https://externals.io/message/6139#6148 · In reply to: #6140

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).

---

## #6150 — Sascha Schumann — 2003-12-03T22:21:25+00:00

URL: https://externals.io/message/6139#6150 · In reply to: #6139

-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

---

## #6151 — George Schlossnagle — 2003-12-03T22:22:17+00:00

URL: https://externals.io/message/6139#6151 · In reply to: #6148

> George Schlossnagle wrote:
> > […]
> On the other hand, there are Common Lisp (foo-bar-baz), Python (mostly 
> foobarbaz) and Ruby (mostly foo_bar_baz).

To be pedantic, the Python style guide 
(http://www.python.org/peps/pep-0008.html) specifies class names to be 
StudlyCaps and method names to be either underscore-delimited or 
StudlyCaps, at the authors leisure.  Of course, PHP is not Python.

George

---

## #6152 — Derick Rethans — 2003-12-03T22:23:05+00:00

URL: https://externals.io/message/6139#6152 · In reply to: #6139

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).

Derick

---

## #6153 — Olivier Hill — 2003-12-03T22:23:35+00:00

URL: https://externals.io/message/6139#6153 · In reply to: #6149

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+(?)

---

## #6154 — Sascha Schumann — 2003-12-03T22:25:57+00:00

URL: https://externals.io/message/6139#6154 · In reply to: #6144

> 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

---

## #6155 — Michael Walter — 2003-12-03T22:26:31+00:00

URL: https://externals.io/message/6139#6155 · In reply to: #6151

George Schlossnagle wrote:
> > […]
> 
> 
> To be pedantic, the Python style guide 
> (http://www.python.org/peps/pep-0008.html) specifies class names to be 
> StudlyCaps and method names to be either underscore-delimited or 
> StudlyCaps, at the authors leisure.  Of course, PHP is not Python.
The latter being my real point :) I don't really have an opinion on the 
subject (I'm fine with either style, as long as it's *consistent*), but 
I felt like pointing out that there isn't really one standard convention 
(as people might get the impression) even if you just consider languages 
supporting OO.

Cheers,
Michael

---

## #6156 — Michael Walter — 2003-12-03T22:28:20+00:00

URL: https://externals.io/message/6139#6156 · In reply to: #6150

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.

---

## #6158 — Michael Walter — 2003-12-03T22:35:10+00:00

URL: https://externals.io/message/6139#6158 · In reply to: #6157

Markus Fischer wrote:
 > [...]
> 	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)

How is this an advantage?

Cheers,
Michael

---

## #6159 — Moriyoshi Koizumi — 2003-12-03T22:39:16+00:00

URL: https://externals.io/message/6139#6159 · In reply to: #6149

> 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

---

## #6161 — Andi Gutmans — 2003-12-03T22:41:11+00:00

URL: https://externals.io/message/6139#6161 · In reply to: #6139

At 11:14 PM 12/3/2003 +0100, Georg Richter wrote:
>I'm -1.
>
>And for ext/mysqli which supports OO, studlyCaps would make life harder, to
>migrate "old" php4 scripts to PHP5 and ext/mysqli.
>
>How about an additional configure option --with-studly-caps (disabled by
>default) and defining some additional aliases?

No matter what the decision, I definitely don't want any configure options 
and no INI options.

Andi

---

## #6163 — Andi Gutmans — 2003-12-03T22:45:02+00:00

URL: https://externals.io/message/6139#6163 · In reply to: #6139

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.

Andi

At 05:50 PM 12/3/2003 -0500, Ilia Alshanetsky wrote:
>-1
>
>*Caps syntax is harder to read & use compared to the underscore based system,
>which we already use. Having 2 separate naming conventions is confusing and
>difficult and you end up with the code which will mix & match both of them
>resulting in confusing and difficult to read code.
>
>Ilia

---

## #6160 — Ilia Alshanetsky — 2003-12-03T22:50:34+00:00

URL: https://externals.io/message/6139#6160 · In reply to: #6139

-1

*Caps syntax is harder to read & use compared to the underscore based system, 
which we already use. Having 2 separate naming conventions is confusing and 
difficult and you end up with the code which will mix & match both of them 
resulting in confusing and difficult to read code.

Ilia

---

## #6166 — Derick Rethans — 2003-12-03T22:57:25+00:00

URL: https://externals.io/message/6139#6166 · In reply to: #6163

> 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

---

## #6167 — Christian Schneider — 2003-12-03T23:03:48+00:00

URL: https://externals.io/message/6139#6167 · In reply to: #6157

Markus Fischer wrote:
> 	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 agree with Markus.

- Chris (I've no cow yet so not voting right but still an opinion)

---

Next page: https://externals.io/message/6139.md?page=2