Jordi Boggiano, lead developer on the Composer has posted about some of the new Composer patterns that have been introduced into the tool this year, including some you might not even have realized.

Here is a short update on some nice little features that have become available in the last year in Composer.

He includes five of these features in his list (but something tells me these are just some of the more user-facing improvements the project has introduced):

• Checking dependencies for bad patterns
• Referencing scripts to avoid duplication
• Defining your target production environment in composer.json
• Excluding paths from the optimized classmap
• Requiring packages easily and safely

For each item he includes the command (and sometimes optional arguments) that make it work and what kind of results you can expect. There's definitely some handy features in here and not just for the "power users" in the crowd.

Matthew Setter has a new post to his Master Zend Framework site today with a recommendation on how you can use a classmap in your autoloader to reduce the time it takes "searching" for the files it needs.

Zend Framework 2′s been critiqued many times as being slow, at least slower than some of the other leading PHP frameworks. And to be fair, sometimes it’s true. But it doesn’t need to be and there are simple things you can do to improve performance of your applications. So this post will be the first in a multi-part series looking at ways in which you can improve the performance of your Zend Framework 2 application, with only a minimum of effort. Today, we’re looking at the 2 autoloaders which are available in Zend Framework 2; these being the StandardAutoloader and ClassMapAutoloader.

He briefly introduces the concept of autoloaders and the PSR-0 standard that helped to bring a more unified method for their handling. He then gets into examples of using each of the two autoloader types. The Standard version (a fallback if nothing else is set up) resolves things based on a file path and locating classes in the right namespaces. The ClassMap autoloader does this mapping ahead of time and matches a path to a namespace+class. He includes code snippets showing how to set each of them up and a few statistics (using Apache's ab tool) of the difference in performance.

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.

On the KnpLabs blog there's a new post from Ryan Weaver sharing some cool things you can do with Composer you might not have known about when managing your application's dependencies.

For those of you that are comfortable with Composer, I wanted to talk about a few lesser-known, but really fantastic features. These are inspired by real questions I've heard while running around the country doing my one-man composer-and-dancing show (i.e. conference talks).

He shares four of them with a fifth that's more of an "upcoming feature" than a current one:

• Autoloading & Performance: "I thought class maps were the fastest?"
• Running Post-Deploy Scripts
• "What if I need to fork a library?"
• Can I host private packages on Packagist?
• What about signing the authenticity of Packages?

That last one about package signing is still on the known issues list and is under discussion, but no doubt that future versions of the tool will support it.

Robert Basic has a new post today about the autoloaders in Zend Framework 1.12 and how to use them to create a classmap for use in your application.

The latest, and last, release of the Zend Framework 1.x series is just around the corner as ZF 1.12.0RC1 was announced this week. As I still have projects running ZF1 I thought about giving the most interesting new feature (for me) a spin - the new autoloaders which are backported from ZF2. I decided using the classmap autoloader as the main autoloader, and the good ol' standard autoloader as the fallback autoloader.

He includes the changes to the Front Controller (index.php) to have it know about these new autoloaders and has a command that will go through your code any pull out any require_once statements out and let the autoloader handle it instead.

In a new post to his blog Rob Allen introduces you to the autoloader that comes with the Zend Framework 2 and shows how to use it to load your own classes.

Autoloading is the process in PHP whereby the system attempts to load a class when it is first encountered (via new or via class_exists) if it hasn't already been loaded via a require or include. Autoload works by looking for a method called __autoload or walking through any method registered with spl_autoload_register. Zend Framework 2 provides the ZendLoaderAutoloader component for autoloading of Zend Framework and your own classes.

The PSR-0-standard tool allows you to load files, set up class mapping and allows for multiple autoloading methods to work side-by-side. He shows how to use the standard autoloading functionality to define paths to locate files (with prefixes and namespaces) in both a constructor-based setup and a more programatic approach. He also shows how to use the ClassMapAutoloader to load from a mapping of class name to class file. Wrapping it up, he shows how to combine the two methods into a single ZendLoaderAutoloaderFactory instance.

In his latest post Volker looks at something he sees more and more projected implementing as a simple way to not have to manually define paths all over their applications - creating autoloaders. His post shows how to create one such autoloader for a legacy, non-framework type of project.

The first argument usually is "ease of use". It can get pretty annoying when you have to clutter your whole application with "require this file here and that file over there" statements. [...] The main motivation for autoloading usually is "getting rid of all the require statements and the problems resulting from forgetting one at one point where you don't notice it because on your machine it worked.

In some projects you're lucky enough to have class name to file name mapping to make it simpler. His project didn't have that, so he needed a way around it. His answer came in the PHP Autoload Builder tool - a handy command line script that works through your code and builds an index of sorts you can refer to for the correct class-to-file map.

Matthew Weier O'Phinney has a new post to his blog (following this post on directory iteration for autoloading) with some of the benchmarks of different methods he tried for automatically loading the libraries his scripts needed on demand.

During the past week, I've been looking at different strategies for autoloading in Zend Framework. I've suspected for some time that our class loading strategy might be one source of performance degradation, and wanted to research some different approaches, and compare performance. In this post, I'll outline the approaches I've tried, the benchmarking strategy I applied, and the results of benchmarking each approach.

His testing included a baseline of the Zend Framework 1.x series loading, a naming/class standard following the PEAR standards and class mapping with file/class name pairs. He includes his benchmarking strategy and the scripts he used to run the tests (on github here). He ran them both with and without opcode caching to give a better overall performance view.