Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:1527
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: <internals@lists.php.net>
Date: Thu, 15 May 2003 13:59:38 +0200
Organization: BackendMedia GbR
Message-ID: <001501c31ad9$76f503a0$4d00a8c0@vandal>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Importance: Normal
Subject: PHP OO naming conventions
From: smith@backendmedia.com ("Lukas Smith")

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