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/

That Podcast:
Episode 8 The one where PSR-0 is dead
October 14, 2014 @ 09:17:50

That Podcast has released their latest episode today, hosted by Beau Simensen and Dave Marshall - Episode #8: The one where PSR-0 is dead ("because controversial titles bring all the hits").

Beau and Dave are back together for another chat, covering conference talks, shellshock, Linux (on floppies), PHP Jeopardy and the marketing machine that is Jeremy Mikola, PHP-FIG, learning about AngularJS with CodeSchool.com and working with the TV on.

Other topics included in the episode are things like Mockery spies, the PSR-7 draft and the mention of middlewares for Laravel 5 from Taylor Otwell on Twitter. You can listen to this latest episode either through the in-page audio player or by downloading the mp3. Don't forget, if you enjoy the show, be sure to subscribe to their feed to get the latest shows as they're released.

0 comments voice your opinion now!
thatpodcast ep8 psr0 podcast beausimensen davemarshall

Link: http://thatpodcast.io/episodes/episode-8-the-one-where-psr-0-is-dead/

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

Ben Ramsey:
The Fall of PEAR and the Rise of Composer
November 27, 2013 @ 09:17:35

Ben Ramsey has an interesting post to his site today looking at what he calls the Fall of PEAR and the rise of Composer when it comes to package management in the PHP community.

PEAR's biggest selling-point -the curation of packages by a governed community - was also its biggest problem. There was no choice, and things moved slowly. If a package stagnated in development, I couldn't find another actively supported one to solve the same need. In theory, the maintenance of the package could be taken over by someone else, but this didn't always happen, and contributing patches was not clear or easy.

Ben talks about how, despite the PEAR development's best efforts, the proposed new package manager (Pyrus and PEAR2) couldn't keep up. Then, from a discussion had at a conference, the idea of a standards group was formed, the PHP-FIG, and the first standard soon followed, PSR-0 for autoloading. With this in hand and becoming widely adopted, a new tool was created to make it easier to share and install packages with this new standard - Composer.

Composer is what PEAR should have been. Through Packagist, Composer is the democratization of PHP userland libraries. Many libraries in the repository implement similar functionality, but through a show of popularity, the community self-selects the packages that are of the best quality. [...] In just a few short years, Composer has revitalized the PHP community and changed the way we do development.
0 comments voice your opinion now!
fall pear rise composer psr0 phpfig package management

Link: http://benramsey.com/blog/2013/11/the-fall-of-pear-and-the-rise-of-composer/

SitePoint PHP Blog:
Battle of the Autoloaders PSR-0 vs. PSR-4
November 25, 2013 @ 13:09:15

The SitePoint PHP blog has a new post from editor Bruno Skvorc about a PSR standard (from the PHP-FIG group) that's proposing and update and slight change to the currently wide-practiced autoloading standard (PSR-0). This new standard, PSR-4, proposes a modification to the PSR-0 spec with a bit more strict guidelines.

If you've gone past the beginner stage in your PHP training, you've heard of PSR-0 - an autoloading standard that defines ways to automatically include PHP classes in your code without having to use statements like require and include. [...] When Composer showed up and took the PHP package management world by storm, things changed. Due to some of its rules, folders often duplicated and became too deep when looking at PSR-0 class installations via Composer. [...] Therefore, some highly qualified PHP devs got together and put together a suggestion for a new standard: PSR-4.

The goal behind PSR-4 is to define a new autoloading standard that removes allowances for things like the underscaore as a "namespacing" tool. Bruno makes some suggestions for the structure of your tools if you're going to go with PSR-4 and the handling of multiple autoloaders/paths in the same namespace.

0 comments voice your opinion now!
psr0 psr4 autloading composer package phpfig

Link: http://www.sitepoint.com/battle-autoloaders-psr-0-vs-psr-4/

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

Tom Butler:
PHP PSR-0 Pretty Shortsighted, Really
April 16, 2013 @ 13:12:14

In a new post to his site Tom Butler gives some reasoning as to why he thinks PSR-0 is shortsighted and some examples of a possible better alternative.

A little background for those unaware of what PSR-0 is: There's a self-declared PHP "standards" group called PHP-FIG attempting to push several "standards" throughout the PHP community. [...] I have little interest in debating the politics behind pushing standards or whether small groups of developers trying to make decisions that affect the entire community is good or not, but I do object to the PSR-0 standard itself. My issues are purely practical, PSR-0 reduces flexibility and makes life more difficult for developers

While he likes the idea of a standard way to be able to include third-party libraries that can be reused in multiple systems, he suggests that it answers the wrong question. In his view, it should be up to the library/tool developers to ensure the structure of their code to work with a standard, not the other way around. He points out that a "standard" is something that should apply to all situations and some of the workarounds that are needed for PSR-0 negate this idea.

In his alternative method, he suggests an "Autloadable" interface that can be implemented by the library/tool that includes a "load" method to handle the actual class loading. Then this autoloader would be registered via a json configuration file for the package. This allows the developer to control the loading and place any exceptions they might need into their own logic instead of trying to work around possible issues with the PSR-0 loading scheme.

PSR-0 is a bad solution to a good problem. If you take anything from reading this post, remember this: If the standard defined how autoloaders could be extended, rather than how autoloaders worked, then each library or vendor could provide its own extension to the autoloader and everyone would be happy.
0 comments voice your opinion now!
psr0 autoload standard opinion shortsighted alternative

Link: http://r.je/php-psr-0-pretty-shortsighted-really.html


Community Events

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


wordpress podcast laravel5 language unittest interview development release framework laravel community library api introduction opinion series extension voicesoftheelephpant psr7 conference

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