Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:1528
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
To: Lukas Smith <smith@backendmedia.com>
Cc: internals@lists.php.net
In-Reply-To: <001501c31ad9$76f503a0$4d00a8c0@vandal>
References: <001501c31ad9$76f503a0$4d00a8c0@vandal>
Content-Type: text/plain
Organization: 
Message-ID: <1052999404.27984.127.camel@hasele>
Mime-Version: 1.0
Date: 15 May 2003 07:50:04 -0400
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHP OO naming conventions
From: sterling@bumblebury.com (Sterling Hughes)

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