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
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.
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. |
`------------------------------------------------------------'
Robert Cummings wrote:
+1 for studlyCaps -- contrast IAmAndi versus nameIsAndi, the chosen
variable name makes all the difference.
-1 on that argument as now the CS dictates what names you may chose
which should be the other way round IMHO
--
Hartmut Holzgraefe <hartmut@php.net
Robert Cummings wrote:
+1 for studlyCaps -- contrast IAmAndi versus nameIsAndi, the chosen
variable name makes all the difference.-1 on that argument as now the CS dictates what names you may chose
which should be the other way round IMHO
It doesn't dictate what names you may choose, but for those who think
IAmAndi lacks aesthetics, then for such people perhaps another choice
would have been better. I was merely pointing out that there are plenty
of alternate choices thus weakening the argument for blunderscore
separation based on the IAmAndi case.
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. |
`------------------------------------------------------------'
Robert Cummings wrote:
+1 for studlyCaps -- contrast IAmAndi versus nameIsAndi, the chosen
variable name makes all the difference.
-1 on that argument as now the CS dictates what names you may chose
which should be the other way round IMHO
ItDoesn'tDictateWhatNamesYouMayChoose,
ButForThoseWhoThinkIAmAndiLacksAesthetics,
ThenForSuchPeoplePerhapsAnotherChoiceWouldHaveBeenBetter.
IWasMerelyPointingOutThatThereArePlentyOfAlternateChoicesThusWeakeningT
heArgumentForBlunderscoreSeparationBasedOnTheIAmAndiCase.
Cheers,
Rob.
I'm_not_sure_why,
but_I_cannot_quickly_and_easily_figure_out_what_you_mean_to_say..
;-)
-Bop
I'm_not_sure_why,
but_I_cannot_quickly_and_easily_figure_out_what_you_mean_to_say..
The cute dig aside, common words are quickly read based on mental
assumptions of word "shapes", and word "breaks" Letter capitalization
means a new sentence, or proper noun, to most english speakers.. The
underscore is easily ignored as a "break" sign in english, hence, the
cheat. Studly caps could be more effective if only nouns had caps, but
CS folks aren't often social-language studies fans, and they cap each
word. OO conventions seem straight out of a language without word
breaks, beyond a new capital for each new word.
shrug
If OO folks can't adopt traditional code, lets bring the code to them,
and allow MysqlExec and mysql_exec... just strip the "_". If it's
slower, well, traditionally OO folks are happy to lose performance to
gain OO.
-Bop
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).
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).
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
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.
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
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.
Neither Readability nor familiarity does matter here.
Moriyoshi
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
Derick Rethans wrote:
haha, with these suckyCaps we have two different styles for core-php
functions; that's worse and that's what we should care about.
+1
And we gain a simple rule of thumb with underscores:
underscores => build-in functionality => referr to php.net/function_name
study => user supplied stuff => referr to pear.php.net/ or example.com/
Ulf
On Thu, 04 Dec 2003 12:09:00 +0100
Ulf Wendel ulf.wendel@phpdoc.de wrote:
Derick Rethans wrote:
haha, with these suckyCaps we have two different styles for core-php
functions; that's worse and that's what we should care about.+1
And we gain a simple rule of thumb with underscores:
underscores => build-in functionality => referr to
php.net/function_name study => user supplied stuff => referr to
pear.php.net/ or example.com/
Absolutely wrong, method overload makes this assumption wrong.
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
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
+1 on studlyCaps
pierre
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
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
-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
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.
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
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)
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
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?
FWIW: it's not only an advantage, it's the reason I strive to use studlyCaps
in my userland functions - because they will never clash on the next php
upgrade (and the whole image* functions is a pain in the butt in that area).
What happens if a php provided object I extended chooses to implement the
same method and call it internally, expecting different results? Upgrading is
enough hasstle.
My 2c + a cow.
Melvyn
=======================================================
FreeBSD sarevok.idg.nl 5.2-BETA FreeBSD 5.2-BETA #0: Wed Dec 3 20:13:44 CET
2003 root@sarevok.webteckies.org:/usr/obj/usr/src/sys/SAREVOK_NOACPI
i386
Melvyn Sopacua wrote:
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?
FWIW: it's not only an advantage, it's the reason I strive to use studlyCaps
in my userland functions - because they will never clash on the next php
upgrade (and the whole image* functions is a pain in the butt in that area).
What happens if a php provided object I extended chooses to implement the
same method and call it internally, expecting different results? Upgrading is
enough hasstle.My 2c + a cow.
Ah, I understand. Never got into former problems as I prefix my
functions/classes with a package prefix. The latter point is
interesting. Although it's true, I think you're just "moving" the
problem into user-space, as it's an inherit "problem" of the language
(no parametric polymorphism, no "non-virtual" calls, in c++
terminology). Like, if you have that 3rd party PHP library, and you
inherit from it, you might as well run into problems if it uses
studlyCaps. It definately removes the problem for built-in php
functionality, though, I completely agree on that.
Cheers,
Michael
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)
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).
So much for consistency ...
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
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
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
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
-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
I'm -1 for suckyCaps.
--Jani
p.s. Why not a mix, e.g. PHP_Object =)
Andi Gutmans wrote:
The facts are the following:
a) Existing PHP functions use underscores.
PHP's internal function names should use _ to delimit between
words.
b) Some external object models such as Java use StudlyCaps.
And this what we should consistently adopt for the naming of PHP's
internal method names.
So, of course, I am +1 for studlyCaps. But regardless of a pro/con
decision on studlyCaps the result must be consistent.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/