PHPDeveloper.orghttp://www.phpdeveloper.org
Up-to-the Minute PHP News, views and communityen-usTue, 03 Mar 2015 16:44:49 -060030http://www.phpdeveloper.org/news/22271http://www.phpdeveloper.org/news/22271
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.

Link: http://blog.bitexpert.de/blog/defining-phing-tasks-in-psr-0-style/]]>Fri, 23 Jan 2015 10:42:49 -0600http://www.phpdeveloper.org/news/21455http://www.phpdeveloper.org/news/21455
In his latest postPhil 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.

Link: http://philsturgeon.uk/blog/2014/07/deprecate-psr0]]>Mon, 21 Jul 2014 09:09:26 -0500http://www.phpdeveloper.org/news/20624http://www.phpdeveloper.org/news/20624
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.

Link: http://philsturgeon.co.uk/blog/2014/01/autoloading-laravel-application-code-with-psr4]]>Thu, 09 Jan 2014 10:13:02 -0600http://www.phpdeveloper.org/news/20606http://www.phpdeveloper.org/news/20606
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.

Link: http://philsturgeon.co.uk/blog/2014/01/composer-now-supports-psr4]]>Mon, 06 Jan 2014 09:59:36 -0600http://www.phpdeveloper.org/news/20596http://www.phpdeveloper.org/news/20596
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 otherresources 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

Link: http://www.reddit.com/r/PHP/comments/1u1ztr/attempting_to_understand_namespacing_and_its]]>Thu, 02 Jan 2014 11:54:23 -0600http://www.phpdeveloper.org/news/20233http://www.phpdeveloper.org/news/20233
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.

Link: http://phpixie.com/blog/benchmarking-autoloading-vs-combining-classes-into-a-single-file/]]>Thu, 10 Oct 2013 11:48:44 -0500http://www.phpdeveloper.org/news/20144http://www.phpdeveloper.org/news/20144
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.

Link: https://groups.google.com/forum/#!topic/php-fig/NWfyAeF7Psk]]>Fri, 20 Sep 2013 12:18:31 -0500http://www.phpdeveloper.org/news/19879http://www.phpdeveloper.org/news/19879
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.

Link: http://blog.calevans.com/2013/07/21/using-3rd-party-libraries-in-composer-projects]]>Mon, 22 Jul 2013 09:37:53 -0500http://www.phpdeveloper.org/news/19562http://www.phpdeveloper.org/news/19562
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" .

Link: http://philsturgeon.co.uk/blog/2013/05/composer-and-psr0-friends-not-relatives]]>Wed, 08 May 2013 11:15:42 -0500http://www.phpdeveloper.org/news/19472http://www.phpdeveloper.org/news/19472
In a response to this previous post about the PSR-0 standard and why it might be "shortsighted", Phil Sturgeon has posted some of his own thoughts on the matter as a participant (and supporter) in the PHP-FIG group.

One of the fun things about trying to support the PHP-FIG and all the good its doing, is seeing blog posts written complaining about it by people that just don't know what they're talking about. I get involved in conversations on Reddit (dangerous I know) on a mission to understand the problems with its perception throughout the community, and try to make more knowledge readily available to avoid confusion. I put together the PHP-FIG FAQ and the rest of the group voted it in, which I believe helped a lot. Sadly some blog posts are sent out by people with a whole bunch of odd opinions that you just can't do anything about, so instead I'm going to respond with a play-by-play approach.

He goes through several of the points Tom made in his original post, pointing out places where the information was either misconceptions or just completely incorrect. He relates some of the autoloading suggestions Tom made back to things Composer can do and how this is different from "magic" on the part of the library user.

PSR-0 has its problems, but they are the two that I have pointed out and they are rather trivial. [...] If you'd like to add custom autoloaders to your Composer packages then go ahead. If you'd like to build your own custom autoloaders for all of your packages then you can do that too, but it ruins the entire purpose of what PSR-0 is meant to do. That's fine, because you don't need to use it, but I am happy as hell that PSR-0 exists and I wouldn't make drastic changes to it for anything.