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
George Schlossnagle 3 December 2003 23:58:02 [ permanent link ]
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.
Eduardo R. Maciel 4 December 2003 00:43:53 [ permanent link ]
I know the valids decision votes will be from the core developers (wich I am not). But Id like to expose my suggestion:
- PHP object oriented parts, like classnames, methods, atributes, etc could use studlyCaps as almost whole world use to with OO code.
- Php procedural parts, like functions, vars, constants, etc could use underscore as almost the whole world use to with not OO code.
Since PHP is a mixed language (procedural and Object Oriented) It would even help to diferentiate each paradigm. The way it would be easy to know when a external module supports OO features for example. And as Andi said, interfacing with external modules and interfacing with other technologies are growing up, and would help if it works like those other technologies. In the other hand, using underscores where code is not OO, would make clear to see that you are using the procedural way.
Just imagine how complicated will it be if PHP programmers has to use several OO modules, and some of them use underscores, PEAR using studlycaps, another framework using undercores too, and other using studly, all Object Oriented. What a mess....
Defining all OO parts of PHP (and recomending it to external modules) as studlyCaps would follow a tendency which ALREADY EXISTS and not force all existant PHP OO code to be rewritten. And would keep things in order. Easy to manage.
In the other hand, defining the use of underscores will break what already exists (about OO Code) and probably wont be accepted as a consensus. Means that what I sad above (the messy code) can happen.
IMO it would the best to do in this situation.
__________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
Robert Cummings 4 December 2003 00:44:26 [ permanent link ]
On Wed, 2003-12-03 at 15:58, 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.
+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. | `------------------------------------------------------------'
Marcus Boerger 4 December 2003 00:51:51 [ permanent link ]
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.
Derick Rethans 4 December 2003 01:03:47 [ permanent link ]
On Wed, 3 Dec 2003, Marcus Boerger wrote:
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.
Markus Fischer 4 December 2003 01:10:37 [ permanent link ]
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.
Michael Walter 4 December 2003 01:14:30 [ permanent link ]
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).
Sascha Schumann 4 December 2003 01:21:25 [ permanent link ]
-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.)
Derick Rethans 4 December 2003 01:23:05 [ permanent link ]
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).
Michael Walter 4 December 2003 01:28:20 [ permanent link ]
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.
Michael Walter 4 December 2003 01:35:10 [ permanent link ]
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.>
Andi Gutmans 4 December 2003 01:42:40 [ permanent link ]
At 11:35 PM 12/3/2003 +0100, Michael Walter 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?
You easily see what is taken from the language and what is user-land code.
Andi Gutmans 4 December 2003 01:45:02 [ permanent link ]
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.>
Michael Walter 4 December 2003 01:46:34 [ permanent link ]
Andi Gutmans wrote:
At 11:35 PM 12/3/2003 +0100, Michael Walter 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?>
You easily see what is taken from the language and what is user-land code.
Yeah, obviously. But what exactly do I gain from that? The only thing I could figure is that when you see an unknown function, you can immediately realize whether to grep the repository, or look on php.net/foo (if course unless using a decent editor). This has never really been a problem for me, though, hence the question. I do realize though, that it might slightly increase beginner-friendliness - is that the reasoning behind that point?
At 11:35 PM 12/3/2003 +0100, Michael Walter 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?>
You easily see what is taken from the language and what is user-land code.
Err but OO code is different than function code because of inheritance. Separating core and userland code like this is absolutely ludicrous because then you don't even need to use OO to begin with. I mean then you might as well stick with functions which isn't what Ulf wants (that's why I was so surprised to see Ulf suggesting something like this).
Ilia Alshanetsky 4 December 2003 01:50:34 [ permanent link ]
-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.
Derick Rethans 4 December 2003 01:57:25 [ permanent link ]
On Thu, 4 Dec 2003, Andi Gutmans wrote:
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.>
Christian Schneider 4 December 2003 02:03:48 [ permanent link ]
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)
Melvyn Sopacua 4 December 2003 03:02:27 [ permanent link ]
On Wednesday 03 December 2003 23:35, Michael Walter 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. -- 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 =======================================================
Michael Walter 4 December 2003 03:27:35 [ permanent link ]
Melvyn Sopacua wrote:> On Wednesday 03 December 2003 23:35, Michael Walter 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.
Sascha Schumann 4 December 2003 12:56:42 [ permanent link ]
On Thu, 4 Dec 2003, Pierre-Alain Joye wrote:
On Thu, 04 Dec 2003 00:42:40 +0200> Andi Gutmans <andi@zend.com> wrote:>
You easily see what is taken from the language and what is user-land> > code.>
This argument is as non revelant as the aesthetic one.
One of the largest cost in software development is maintenance. One key factor regarding maintainability is readability and understandability. These issue cannot be simply dismissed as irrelevant as you try to make it.
Of course, it is always easier to simply dismiss arguments which don't support your point. The price? Your credibility.
Pierre-Alain Joye 4 December 2003 13:03:57 [ permanent link ]
On Thu, 4 Dec 2003 10:56:42 +0100 (CET) Sascha Schumann <sascha@schumann.cx> wrote:
One of the largest cost in software development is> maintenance. One key factor regarding maintainability is> readability and understandability. These issue cannot be> simply dismissed as irrelevant as you try to make it.
I have to agree. But that does not match the readability argument told here, as the readability (subjective) enhancement is so small regarding to the additionnal work due to non studlyCaps internal *methods*.
However I fully agree with you when you say that should be anyway up to the extension maintainers (ie a binder requering _ like mysql). That's why I rather prefer to set a recommandation (to be used by default) and , only if _required_ for easyness/technical reasons, use the alternative naming.
Of course, it is always easier to simply dismiss arguments> which don't support your point. The price? Your> credibility.
Derick Rethans 4 December 2003 13:06:36 [ permanent link ]
On Thu, 4 Dec 2003, Pierre-Alain Joye wrote:
On Thu, 4 Dec 2003 10:56:42 +0100 (CET)> Sascha Schumann <sascha@schumann.cx> wrote:>
One of the largest cost in software development is> > maintenance. One key factor regarding maintainability is> > readability and understandability. These issue cannot be> > simply dismissed as irrelevant as you try to make it.>
I have to agree. But that does not match the readability argument told> here, as the readability (subjective) enhancement is so small regarding> to the additionnal work due to non studlyCaps internal *methods*.
I don't see the "additional work" part here...how is it going to create extra work for the PHP developers?
Robert Cummings 4 December 2003 13:24:42 [ permanent link ]
On Thu, 2003-12-04 at 05:07, Hartmut Holzgraefe wrote:> 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. | `------------------------------------------------------------'
Ronald Chmara 4 December 2003 13:47:33 [ permanent link ]
On Dec 4, 2003, at 5:24 AM, Robert Cummings wrote:> On Thu, 2003-12-04 at 05:07, Hartmut Holzgraefe wrote:>> 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.
Ronald Chmara 4 December 2003 14:06:58 [ permanent link ]
On Dec 4, 2003, at 5:47 AM, Ronald Chmara wrote:> 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.
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:
Pierre-Alain Joye 4 December 2003 14:11:34 [ permanent link ]
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:>
Sebastian Bergmann 6 December 2003 13:00:52 [ permanent link ]
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).
On Sat, Dec 06, 2003 at 10:59:33AM +0100, Sebastian Bergmann 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.
But i guess the only solution that both parties will accept is dynamically removing all underscores from names when calling a function/method (that would clear up the strpos/str_replace etc inconsistency as well).
-- Regards, Stefan Walk <swalk@prp.physik.tu-darmstadt.de>
George Schlossnagle 6 December 2003 19:45:12 [ permanent link ]
On Dec 6, 2003, at 11:14 AM, Stefan Walk wrote:
On Sat, Dec 06, 2003 at 10:59:33AM +0100, Sebastian Bergmann 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 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.
But i guess the only solution that both parties will accept is> dynamically removing all underscores from names when calling a> function/method (that would clear up the strpos/str_replace etc> inconsistency as well).
Huh? That's awful. Who supports that sort of magic?
Andrey Hristov 6 December 2003 19:58:22 [ permanent link ]
George Schlossnagle wrote:
On Dec 6, 2003, at 11:14 AM, Stefan Walk wrote:>
On Sat, Dec 06, 2003 at 10:59:33AM +0100, Sebastian Bergmann 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.
George Schlossnagle 6 December 2003 20:06:55 [ permanent link ]
On Dec 6, 2003, at 11:58 AM, Andrey Hristov wrote:> 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.
This whole issue is non-technical and purely stylistic. Neither outcome would keep anyone from achieving anything, it may just make life more difficult for the PEAR folks.
On Sat, Dec 06, 2003 at 11:45:12AM -0500, George Schlossnagle wrote:> >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>
Cristiano Duarte 6 December 2003 23:14:16 [ permanent link ]
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.
George Schlossnagle 7 December 2003 04:42:05 [ permanent link ]
On Dec 6, 2003, at 12:40 PM, Stefan Walk wrote:
On Sat, Dec 06, 2003 at 11:45:12AM -0500, George Schlossnagle wrote:>>> 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.)
That's great, but we're not discussing Ruby, we're discussing PHP. No amount of underscores in Ruby effects the fact that PEAR, which is a defacto part of PHP, has standardized on StudlyCaps and has a large amount of code written that way.>
Huh? That's awful. Who supports that sort of magic?>
That's not much more magic than case-insensitive functions.
I'm not a fan of case-insensitivity. If you propose removing that in PHP5, you'll get my vote (and many others).
If you would like to report an abuse of our service, such as a spam message, please . Если Вы хотите пожаловаться на содержимое этой страницы, пожалуйста .
![[PHP-DEV] StudlyCaps](http://qaix.com/i/logo_new.gif){kind=logo}
