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

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

Chris Hartjes:
Standards, Soapboxes, and Shamans
January 21, 2013 @ 13:16:47

In this latest post to his site Chris Hartjes shares some of his thoughts about the recently approved PSR-3 standard (for logging) and some of the reception that the other PSRs (PSR-0, 1 & 2) have gotten from the PHP community.

For those who pay attention to the workings of the PHP community you might have heard about the "PHP Standards Recommendations" that have been coming out of the PHP Framwork Interop Group. [...] More recently this group has been working on a standard for logging interfaces called PSR-3. I spoke about this on Twitter, and I will repeat it here: I think PHP programmers should get behind PSR-0 and efforts like PSR-3. I feel that PSR-1 and PSR-2 are solutions looking for a problem and seem, to me anyway, to me out of place with the solutions offered by PSR-0 and PSR-3.

He likens the PHP PSRs to the Python enhancement proposals (PEPs) and, more specifically, to the PEP-8 - their own version of "coding standards" that was highly championed by Guido van Rossum and put into wide practice.

Any programming language community that does not work as hard as possible to make it easier to integrate other's libraries of code together [by standardizing their formatting] is asking for irrelevancy.
0 comments voice your opinion now!
standards psr0 psr1 psr2 psr3 community feedback python pep


Project:
CodeSniffer for PSR's (PSR-0, PSR-1 & PSR-2)
June 09, 2012 @ 11:17:50

Klaus Silveira has created a set of PHP_CodeSniffer rules that can be used to test your code for the recently approved PSR-1 & PSR-2 standards.

This is a PHP_CodeSniffer sniff to check against the PHP Standard Resolutions: PSR-0, PSR-1 and PSR-2. Those standards were approved by the PHP Framework Interoperability Group. You can read more about the PHP FIG and the PSR's on this excellent article by Paul Jones.

The github repository also provides an overview of the standards themselves and how to get these sniffs installed.

0 comments voice your opinion now!
psr codesniffer rules psr0 psr1 psr2



Community Events





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


opinion release unittest testing developer introduction wordpress list experience podcast install refactor language laravel code framework community series interview threedevsandamaybe

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