PHP OO naming conventions

php.internals

Lukas Smith

23 years ago
Hi, *Disclaimer* I am only talking about the API that is exposed to the user and not about any CS that don't relate to this (brackets, indenting etc.). *Disclaimer* As PHP development is beginning to expose more and more functionality through an OO interface we should address the CS for that API now. I think it would be wise not to use the current PHP naming conventions as they are not that well fit for the OO syntax we have in PHP. A pretty lame example to illustrate what I mean: $foo->get_bar(); $foo->get->bar(); Also it would be useful for the user to easily differentiate the different interfaces from each other because otherwise there maybe confusions about different parameter handling in functions/methods due to the nature that the OO interface will require different parameters than the functional counterpart in a lot of cases. Another constructed example: execute_query($connection, $query, $param); $foo->execute_query($query, $param); This should also make life easier for syntax highlighter ... I would therefore propose to use studlyCaps as the CS for PHP OO APIs. Current: $foo->execute_query($query, $param); New: $foo->executeQuery($query, $param); This CS is already known to people in the PHP world (or atleast a considerable amount) in the form of the PEAR CS. This would also be great for PEAR as then it would become possible for them to just extend these classes instead of having to wrap all methods to fit the PEAR CS. FYI: PEAR is also working on defining some standard method names. Like the common issue of close vs. disconnect etc. This might be a good opportunity to maybe also start off "clean" for PHP OO API's in that regard. FYI: I was told that there are no technical reasons that would make it a big deal to have different function and method names provided by one extension. Regards, Lukas Smith smith@backendmedia.com _______________________________ BackendMedia www.backendmedia.com berlin@backendmedia.com Linn Zwoch Smith GbR Pariser Str. 44 D-10707 Berlin Tel +49 30 83 22 50 00 Fax +49 30 83 22 50 07

Sterling Hughes

23 years ago
I agree with lukas - I think our methods should follow studlyCap naming conventions. -Sterling On Thu, 2003-05-15 at 07:59, Lukas Smith wrote:
> Hi, > > *Disclaimer* > I am only talking about the API that is exposed to the user and not > about any CS that don't relate to this (brackets, indenting etc.). > *Disclaimer* > > As PHP development is beginning to expose more and more functionality > through an OO interface we should address the CS for that API now. > > I think it would be wise not to use the current PHP naming conventions > as they are not that well fit for the OO syntax we have in PHP. > > A pretty lame example to illustrate what I mean: > $foo->get_bar(); > $foo->get->bar(); > > Also it would be useful for the user to easily differentiate the > different interfaces from each other because otherwise there maybe > confusions about different parameter handling in functions/methods due > to the nature that the OO interface will require different parameters > than the functional counterpart in a lot of cases. > > Another constructed example: > execute_query($connection, $query, $param); > $foo->execute_query($query, $param); > > This should also make life easier for syntax highlighter ... > > I would therefore propose to use studlyCaps as the CS for PHP OO APIs. > > Current: $foo->execute_query($query, $param); > New: $foo->executeQuery($query, $param); > > This CS is already known to people in the PHP world (or atleast a > considerable amount) in the form of the PEAR CS. This would also be > great for PEAR as then it would become possible for them to just extend > these classes instead of having to wrap all methods to fit the PEAR CS. > > FYI: PEAR is also working on defining some standard method names. Like > the common issue of close vs. disconnect etc. This might be a good > opportunity to maybe also start off "clean" for PHP OO API's in that > regard. > > FYI: I was told that there are no technical reasons that would make it a > big deal to have different function and method names provided by one > extension. > > Regards, > Lukas Smith > smith@backendmedia.com > _______________________________ > BackendMedia > www.backendmedia.com > berlin@backendmedia.com > > Linn Zwoch Smith GbR > Pariser Str. 44 > D-10707 Berlin > > Tel +49 30 83 22 50 00 > Fax +49 30 83 22 50 07
-- "I can't give you a brain, so I'll give you a diploma" - The Great Oz, The Wizard of Oz

Derick Rethans

23 years ago
On Thu, 15 May 2003, Sterling Hughes wrote:
> I agree with lukas - I think our methods should follow studlyCap naming > conventions.
same here, not because I like them, but because it's a standard. (I would hate to see this happen for normal functions though). Derick
-- "my other box is your windows PC" ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ -------------------------------------------------------------------------

Per Lundberg

23 years ago
On Thu, 2003-05-15 at 13:50, Sterling Hughes wrote:
> I agree with lukas - I think our methods should follow studlyCap naming > conventions.
The only problem is it looks so ugly... :-) Aren't there anyone here that prefers the CapitalizeAllWords() approach?
-- Best regards, Per Lundberg / Capio ApS Phone: +46-18-4186040 Fax: +46-18-4186049 Web: http://www.nobolt.com

George Schlossnagle

23 years ago
On Thursday, May 15, 2003, at 12:04 PM, Per Lundberg wrote:
> On Thu, 2003-05-15 at 13:50, Sterling Hughes wrote: >> I agree with lukas - I think our methods should follow studlyCap >> naming >> conventions. > > The only problem is it looks so ugly... :-) > > Aren't there anyone here that prefers the CapitalizeAllWords() > approach?
Traditionally that is used for types (classes and interfaces in php), while the capatilizeAllButFirst is used for methods.

l0t3k

23 years ago
+1 for studlyCaps. i'd have to rewrite a sh*tload of code otherwise <g> "Sterling Hughes" <sterling@bumblebury.com> wrote in message news:1052999404.27984.127.camel@hasele...

Derick Rethans

23 years ago
On Thu, 15 May 2003, l0t3k wrote:
> +1 for studlyCaps. i'd have to rewrite a sh*tload of code otherwise <g>
You wouldnt have to rewrite anything, we're just suggesting to use the studlyCaps naming scheme for class methods that are exported by PHP extensions. Derick
-- "my other box is your windows PC" ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ -------------------------------------------------------------------------

Alan Knowles

23 years ago
well actually their going to be exported as studlycaps as methods arent case sensative :) = but thats a whole different issue :) Regards Alan Derick Rethans wrote:
>On Thu, 15 May 2003, l0t3k wrote: > > > >>+1 for studlyCaps. i'd have to rewrite a sh*tload of code otherwise <g> >> >> > >You wouldnt have to rewrite anything, we're just suggesting to use the >studlyCaps naming scheme for class methods that are exported by PHP >extensions. > >Derick > > >
-- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com

Derick Rethans

23 years ago
On Fri, 16 May 2003, Alan Knowles wrote:
> well actually their going to be exported as studlycaps as methods arent > case sensative :) = but thats a whole different issue :)
No put no oil on tha fire mate :) Derick
-- "my other box is your windows PC" ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ -------------------------------------------------------------------------

Maxim Maletsky

23 years ago
On Thu, 15 May 2003 13:59:38 +0200 "Lukas Smith" <smith@backendmedia.com> wrote:
> I would therefore propose to use studlyCaps as the CS for PHP OO APIs. > > Current: $foo->execute_query($query, $param); > New: $foo->executeQuery($query, $param);
I personally don't really like studyCaps as any naming convention in PHP for two reasons: 1. PHP rarely uses it 2. Could be confusing for user just my own .02 cents
-- Maxim Maletsky maxim@php.net

George Schlossnagle

23 years ago
On Thursday, May 15, 2003, at 01:46 PM, Maxim Maletsky wrote:
> > On Thu, 15 May 2003 13:59:38 +0200 > "Lukas Smith" <smith@backendmedia.com> wrote: > >> I would therefore propose to use studlyCaps as the CS for PHP OO APIs. >> >> Current: $foo->execute_query($query, $param); >> New: $foo->executeQuery($query, $param); > > I personally don't really like studyCaps as any naming convention in > PHP for > two reasons: > > 1. PHP rarely uses it
PHP itself has almost no objects defined in extensions. PEAR does though, and is widely considered to be 'the standard' for writing OO perl. And it has studlyCaps as one of it's CS standards. gs

George Schlossnagle

23 years ago
On Thursday, May 15, 2003, at 01:48 PM, George Schlossnagle wrote:
>> > > PHP itself has almost no objects defined in extensions. PEAR does > though, and is widely considered to be 'the standard' for writing OO > perl.
^^^^ clearly I meant PHP.... Perl actually has no good defining standard for this in CPAN. /me needs to read before hitting send, apparently. George

(Marcus Börger)

23 years ago
At 19:48 15.05.2003, George Schlossnagle wrote:
>On Thursday, May 15, 2003, at 01:46 PM, Maxim Maletsky wrote: > >> >>On Thu, 15 May 2003 13:59:38 +0200 >>"Lukas Smith" <smith@backendmedia.com> wrote: >> >>>I would therefore propose to use studlyCaps as the CS for PHP OO APIs. >>> >>>Current: $foo->execute_query($query, $param); >>>New: $foo->executeQuery($query, $param); >> >>I personally don't really like studyCaps as any naming convention in PHP for >>two reasons: >> >>1. PHP rarely uses it > >PHP itself has almost no objects defined in extensions. PEAR does though, >and is widely considered to be 'the standard' for writing OO perl. And it >has studlyCaps as one of it's CS standards.
Yes! For PHP4 only domxml made some more use of OO from within an extension. And domxml is an exception itself since it has to follow W3C naming. With PHP 5 this will change so i think it is a very good idea to use the same naming convention PEAR already uses. (Now it is little work) marcus