Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Stephan Hochdörfer:
Defining Phing Tasks in PSR-0 style
Jan 23, 2015 @ 10:42:49

In his latest post Stephan Hochdörfer shows you how to define Phing tasks according to the PSR-0 autoloading format. Phing is a PHP-based automation tool that uses an XML configuration to execute a series of tasks.

Before anybody complains: I know that "as of 2014-10-21 PSR-0 has been marked as deprecated. PSR-4 is now recommended as an alternative." - Anyway I still think this little gem makes sense to be shared because a lot of people are probably not aware of it. I recently found out by accident that it is possible pass a task name in PSR-0 style to the "taskdef" task. In the old days you had to use the Java-like dot-style notation like this and also define the classpath to make sure the class could be loaded correct! This is ok if the task resides in the same project. If the task is located in a dependent package loaded via Composer this can get ugly.

The post is quick but provides two very handy code examples, one showing the old "dot notation" version and the other showing how to make use of the autoloader. The trick is in the classname value and using the full namespace/class name rather than the dot notation.

tagged: phing build task psr0 classname path autoload

Link: http://blog.bitexpert.de/blog/defining-phing-tasks-in-psr-0-style/

Phil Sturgeon:
Send PSR-0 to the Standards Farm in the Sky
Jul 21, 2014 @ 09:09:26

In his latest post Phil Sturgeon makes a request of the PHP community - to "send PSR-0 to to Standards Farm in the Sky". Or, to put it another way, deprecate it in favor of the more recent autoloader handling of PSR-4.

This article attempts to convince you that deprecating the PSR-0 auto-loading standard in favor of the PSR-4 auto-loading standard is not only a good idea, but a problemless wonderland of happy benefits, in the hope that when I try to get this done on the FIG mailing list, people will be happy about it instead of sad or rage-mode. [...] I believe it was talked about as an alternative at the time because we knew that the PHP community would drop their collective bricks if we tried to pull PSR-0 out from under them, right as they were just slowly getting used to using it.

He covers a few different topics and his opinions on each including the "hate" for PSR-0 (for wanting to get rid of it) and why it should even be considered for deprecation in the first place. He also reminds readers that he's advocating the deprecation of PSR-0, not the removal of it as a standard. It can still exist and be used but it will no longer be the "moving forward" method of autoloading (in favor of PSR-4). He also comments on the large user base out there on PHP <=5.2 that wouldn't be able to make the update to PSR-4 and a suggestion to projects wanting to encourage the migration.

tagged: deprecate psr0 standards psr4 autoload

Link: http://philsturgeon.uk/blog/2014/07/deprecate-psr0

Phil Sturgeon:
Autoloading Laravel application code with PSR-4
Jan 09, 2014 @ 10:13:02

On his site today Phil Sturgeon has a new post showing how to use autoloading with Laravel based on the recently approved PSR-4 standard.

The video shows you how to move over from the current autoloading methods, PSR-0, for your own packages, not Laravel's. He walks you through the creation of the typical PSR-0 package structure and classes then shows it in use in a simple controller.

The font's a bit small on the screencast, but it gets the idea across. Migrating over to the new autoloading is relatively easy, it just takes a little tweaking on the current structure.

tagged: screencast autoload laravel autoload psr0 psr4 tutorial

Link: http://philsturgeon.co.uk/blog/2014/01/autoloading-laravel-application-code-with-psr4

Phil Sturgeon:
Autoloading Laravel application code with PSR-4
Jan 09, 2014 @ 10:13:02

On his site today Phil Sturgeon has a new post showing how to use autoloading with Laravel based on the recently approved PSR-4 standard.

The video shows you how to move over from the current autoloading methods, PSR-0, for your own packages, not Laravel's. He walks you through the creation of the typical PSR-0 package structure and classes then shows it in use in a simple controller.

The font's a bit small on the screencast, but it gets the idea across. Migrating over to the new autoloading is relatively easy, it just takes a little tweaking on the current structure.

tagged: screencast autoload laravel autoload psr0 psr4 tutorial

Link: http://philsturgeon.co.uk/blog/2014/01/autoloading-laravel-application-code-with-psr4

Phil Sturgeon:
Composer now supports PSR-4
Jan 06, 2014 @ 09:59:36

As Phil Sturgeon notes in a recent post to his site, the Composer, the popular PHP package management tool, now supports the PSR-4 autoloading standard as defined by the PHP-FIG.

PSR-4 was voted in as an "accepted" PSR by the FIG in December. It took a little while to get done and went through a series of painful rewrites but when we have in the end is a document that reflects what this truly is: an improvement on PSR-0.

Today Jordi Boggiano merged a pull request by Andreas Hennings into master branch of Composer that contained support for PSR-4. Andreas was a massive help to the FIG while we were trying to shake the issues out of PSR-4 during Draft and Review stages, so he really outdone himself by providing the code too.

Phil makes a few suggestions about moving to PSR-4 including: not moving immediately, making a "psr4" branch to test it out and points to an example of how to do it. More information on PSR-4 and Composer can be found in the official documentation.

tagged: composer psr4 autoload standard phpfig support

Link: http://philsturgeon.co.uk/blog/2014/01/composer-now-supports-psr4

Reddit.com:
Attempting to understand Namespacing, and its benefits
Jan 02, 2014 @ 11:54:23

If you're relatively new to PHP, you may have read about something called "namespacing" but not fully understood it or the benefits it provides. Over on Reddit, there's a recent discussion where the poster asks about just that:

As I understand it, Namespacing provides a lot of useful context for developers, as well as making the autoloading of classes much easier (though I've never personally tried this). I can also see it being used in a large enough application where it might help keep things in scope, but this seems like a bit of a stretch to me. Apart from that, I'm not too clear on what namespacing actually does.

The comments to the thread including things like links to other resources and other suggestions like:

  • tools to try out
  • places to start using it in your own code
  • the difference between underscores and real namespacing
  • how they help avoid conflicts in naming and functionality
tagged: namespace benefit context autoload opinion discussion

Link: http://www.reddit.com/r/PHP/comments/1u1ztr/attempting_to_understand_namespacing_and_its

PHPixie:
Benchmarking Autoloading vs Combining classes into a single file
Oct 10, 2013 @ 11:48:44

On the PHPixie site there's a new post comparing the overall performance of autoloading versus a single-file approach when it comes to getting the best for your application. They point to the Fat-free Framework as an example of the single file approach.

Thinking about ways of further improving PHPixie I started looking at other projects for inspiration. For example the Fat-Free framework boasts on being contained in a single file. This got me thinking about making a tool for merging all project classes together with vendor libraries into a single for performance boost. MAking such a tool is a fairly trivial task, but still I wanted to be sure it would actually be useful, so I decided to benchmark autoloading classes with composer vs combining them into a single file.

The test script for the benchmarking is included in the post as well as the results from their test runs. In some the XCache extension was used to cache the opcodes, showing a noticeable change from the single-file approach. There's also a measurement of an average framework (autoloaded) request versus the all-in-one method with slightly surprising results. The post also ends with a recommendation for the Composer users out there - using the optional flag to generate a classmap to (slightly) help with autoloading speed.

tagged: benchmark autoload phpixie combined class performance

Link: http://phpixie.com/blog/benchmarking-autoloading-vs-combining-classes-into-a-single-file/

Community News:
PHP-FIG Voting on PSR-4 Opened
Sep 20, 2013 @ 12:18:31

The PHP-FIG has officially started the voting process for the PSR-4 autoloading standard that would provide an interface to make autoloading a bit more standardized across applications.

The purpose is to specify the rules for an interoperable PHP autoloader that maps namespaces to file system paths, and that can co-exist with any other SPL registered autoloader. This would be an addition to, not a replacement for, PSR-0.

The current autoloading standard definition (PSR-0) still allows for the use of the underscore in class names to resolve to directory paths in the application's files. In this new standard, that allowance is gone, relying only on the actual namespacing to define package pathing. This "package-oriented autoloading" is set to help move PHP package development forward into a more standardized structure.

tagged: psr4 voting process open member autoload definition

Link: https://groups.google.com/forum/#!topic/php-fig/NWfyAeF7Psk

Cal Evans:
Using 3rd party libraries in Composer projects
Jul 22, 2013 @ 09:37:53

In this new post to his site, Cal Evans shares a handy tip for those using non-Composer libraries in a Composer-friendly project - using classmaps to bridge the gaps.

A problem I ran into when starting this project is that the official MailChimp API wrapper for PHP is NOT a Composer package. Thankfully, the wizards behind Composer have thought this through. To facilitate using non-Composer packages in composer projects, all I had to do is add one line to my "autoload" section of my project.

Using this "autoload" section, you can get Composer to add the path as a namespace to the class mapping. This lets it load them up in the same way i would any other PSR-0 formatted package. This will even work if you have libraries that aren't PSR-0 as it finds all of the files and pulls them into the map automatically.

tagged: composer project thirdparty library psr0 autoload classmap

Link: http://blog.calevans.com/2013/07/21/using-3rd-party-libraries-in-composer-projects

Phil Sturgeon:
Composer and PSR-0: Friends, Not Relatives
May 08, 2013 @ 11:15:42

Phil Sturgeon has a new post today that looks at the relationship between the PSR-0 standard (autoloading structure) and Composer - noting that they're friends, not relatives.

As a huge proponent of Composer, a happy user of PSR-0 and a voting member on the PHP-FIG I get into plenty of conversations about all of them and it worries me how much confusion there is in the community about these things not actually being related. [...] It seems that a lot of folks discover Composer and PSR-0 at the same time and seem to assume they are the same thing - especially since both Composer and PSR-0 have the idea of a "vendor" and a "package", but those two things are not related to each other either. These are a few points that I have wanted to clarify during some strange conversations over the last few weeks.

He goes on, trying to clear up some of the confusion around the idea of "vendors" and vendor names. He talks about naming schemes and how they may or may not be related to the vendor name on the package. He looks at the PSR-0 loading methods and how the structure of the library/repository effects that (noting that Composer can be made to accommodate something not PSR-0 by default). He suggests that PSR-0 needs to remain "implementation agnostic" and that Composer, at the same time, should remain "specification agnostic" .

tagged: composer psr0 autoload vendor package relationship

Link: http://philsturgeon.co.uk/blog/2013/05/composer-and-psr0-friends-not-relatives