News Feed
Sections




News Archive
feed this:

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
January 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.

0 comments voice your opinion now!
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
July 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.

0 comments voice your opinion now!
deprecate psr0 standards psr4 autoload

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

Phil Sturgeon:
Autoloading Laravel application code with PSR-4
January 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.

0 comments voice your opinion now!
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
January 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.

0 comments voice your opinion now!
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
January 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
0 comments voice your opinion now!
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
October 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.

0 comments voice your opinion now!
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
September 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.

0 comments voice your opinion now!
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
July 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.

0 comments voice your opinion now!
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" .

0 comments voice your opinion now!
composer psr0 autoload vendor package relationship

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

Phil Sturgeon:
Is PSR-0 Shortsighted, or are you?
April 17, 2013 @ 09:14:42

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.
0 comments voice your opinion now!
psr0 autoload opinion response phpfig composer

Link: http://philsturgeon.co.uk/blog/2013/04/is-psr0-shortsighted-or-are-you


Community Events

Don't see your event here?
Let us know!


series laravel threedevsandamaybe framework podcast introduction voicesoftheelephpant library api unittest community language version release opinion security symfony laravel5 interview extension

All content copyright, 2015 PHPDeveloper.org :: info@phpdeveloper.org - Powered by the Solar PHP Framework