Web App Development - Systems Architecture - API Building - Security Audits

Recommended PHP Standards Group

Posted by David in Open Source, PEAR, PHP, industry, innovation
Monday, June 8th, 2009 at 15:03

Introduction

A few weeks ago, Helgi and I attended PHP|Tek 2009 in Chicago, as both representatives of echolibre and The PEAR Group.

This post will briefly discuss the formation of a Recommended PHP Standards Group, as put forward by a meeting of PHP developers at the conference. As would be expected, a bit of controversy surrounds this proposal, but my hope would be that it would be accepted and grow within the global PHP community in the coming years.

As posted by Travis Swicegood, a group of community project representatives came together to discuss naming standards for PHP 5.3 and above. (I would like to take the opportunity to publicly thank the staff of the PHP|Tek conference for providing us with a large meeting room with little more than 2 hours notice).

So, what’s this all about?

With PHP 5.3 being closer to a stable release, the inclusion of namespaces and packaging within projects will take on a whole new meaning for large projects. People representing The PEAR Group (PEAR2), The Zend Framework, Cake PHP, Solar PHP, Agavi and unofficial representatives of Symfony and Phing met together and we discussed standards that could benefit each of the projects and the community in general.

Attending were

Being a PEAR representative with Travis, Helgi and Brett we brought to the table the feedback and problems that we have been facing over the past year and a half with namespacing standards discussions, Matthew Weier O’Phinney from the Zend Framework brought their issues, same for Agavi, Solar, Cake and Symfony (Stefan is an unofficial representative). We brewed and stormed our issues, brought solutions and came up with a standard for namespacing and package structure.

Sneak Preview

Here are a few hints about the standards (outlined on this page) which cover things like namespace packaging structure, exceptions, abstract class naming, interface naming, and concrete class naming.

Namespaces

All packages should be named:
<vendor>\<package_or_component>\<ClassName>

Example:

1
2
3
4
5
<?php
    namespace pear2\text_diff\Diff;
    namespace zend\controller\FrontController;
    namespace cake\models\DatabaseModel;
?>

Exception Naming

  • All packages must declare at package level Exception (i.e., pear2\text_diff\Exception)
  • All packages should use SPL Exceptions where applicable

All of the above mentioned projects consented to this standard as of PHP 5.3. What this means to users and developers is that the barrier for entry from one framework to another becomes greatly reduced and the interoperability of packages between projects is tremendously improved.

You can leave a response, or trackback from your own site.

Comments (11 Responses)

Shane

Can you explain the reasoning behind namespaces having the be lowercase where as class names have to be CamelCase?

The reason is quite simple, it’s to be consistent with other languages as such as Python, RoR, Java and it’ll eliminate confusion for developers. IE: Should the namespace be named ZendFramework or zendFramework, and should it be named cakePHP or CakePHP.

If the namespaces are all lowercase you keep consistency with other languages but also make it much easier for developers making packages for “x” vendor.

[...] echolibre blog » Blog Archive » Recommended PHP Standards Group [...]

[...] the echolibre blog there’s a recent post looking at the recent meeting of the (Recommended) Standards Group at this year’s php|tek: [...]

Shane

I get the consistency thing.

As far as making it easier for developers, that doesn’t seem like much of a reason to me. The developer still has to use CamelCasing for the actual class name.

In your example you use FrontController. Do you imagine having CamelCasing for class names makes it harder for developers making classes for package “x”? Is it Frontcontroller FrontController or frontController?

Also, due the namespaces all beginning with lowercase does this also impose the standard that directory names for packages should always being with a lowercase letter?

Currently in the Zend Framework all directory names being with an uppercase letter.

/srv/library/Zend/Controlller/Front/Action.php

With lower-cased namespaces, would this become:

/srv/library/zend/controller/front/action.php

?

Thanks :)

Hi Shane, to answer your questions:

“Is it Frontcontroller FrontController or frontController?”

Since the convention for naming classes has always been and will continue to be the same, the correct answer is “FrontController”. This is per the PEAR standard, and is used in most PHP libraries.

“Also, due the namespaces all beginning with lowercase does this also impose the standard that directory names for packages should always being with a lowercase letter?”

Yes, the standard stipulates that there should be a 1:1 correspondence between casing of class and file names, and namespace and directory names, so the correct way to name the file would be:

/srv/library/zend/controller/front/Action.php

Hope that helps.

David,

zend\FrontController_Action

why the breakage? I can see the lower-case vendor name.

But the rest, I would have thought it’s:
library/zend/FrontController/Action.php

But you propose:
library/zend/controller/front/Action.php

This makes little sense what so ever? Why is controller before front and why are controller and front split, and why are they *all* lowercase now when the current CS is different?

Till

Sorry, meant to ask Nate. ;-)

ace

Can you give an example of an actual class defintion for instance
DatabaseModel.

To me it seems logical like this:

<?php
namespace cake\models;

class DatabaseModel {

}

Meaning that actual ClassName does not repeat in the namespace.

ace

Aditionaly could you give an example what happens if DatabaseModel has sub classes, for example Exception.

I would do it like this:

<?php
namespace cake\models\database_model;

class Exception extends cake\Exception {

}

[...] Recommended PHP Standards Group (by David Coallier; 8 Jun 2009) [...]

Leave a comment




About this blog

We like to blog about things we're passionate about. We love PHP, MySQL, CouchDB, Linux, Apache - web development standards. We also like writing about building web apps and working with web technology.
You can email us on freedom@echolibre.com

Follow us on Twitter

Eamon Leonard - @EamonLeonard
David Coallier - @DavidCoallier
Helgi Þormar Þorbjörnsson - @h
J.D Fitz.Gerald - @jdfitzgerald
Noah Slater - @nslater
Court Ewing - @courtewing

 

 

 

echolibre limited is registered in Ireland, company number 451576. Directors: Eamon Leonard, J.D Fitz.Gerald. Registered Office: 64 Dame Street, Dublin 2, Ireland.