New on DevShed there's the latest part of a series of tutorials they've written up (fifth of eight) about building automatic loading functionality into your applications. This time they change up their class to make the their loading function accessible outside of a class object.

To avoid an eventual (and unnecessary) instantiation of the loader class, it would be helpful to declare the mentioned "load()" method static. Thus, bearing in mind this important concept, in this fifth part of the series I'm going to enhance the signature of the "Loader" class created previously by turning its loading method into a static one.

They change the definition of the function to be "public static" making it callable both through the "self" keyword and outside the class with the "::" operator.

DevShed has posted part three of their series looking at loader applications in PHP using the __autoload magic method.

While this file loading class in its current incarnation does a pretty good job, it lacks an important feature that could be added with relative ease. It cannot perform a recursive search through the web server's file system, and afterward include a specified file within a given application.

This article updates their class with a new feature to let the script looking for files recursively in a directory.

DevShed continues their "loaders in applications" series with this fourth part, a look at including files recursively.

This series uses a variety of code samples to teach you how to create modular programs. These programs are capable of recursively including files required by a given application, without having to explicitly call any "include()/include_once()" or "require()/require_once()" PHP function.

In their example they show how to use their loader class (built up from previous parts of the series) and modify it slightly to allow the script to set the file path, set the files to include and pull them in.

Continuing their look at static methods in PHP, DevShed has posted this new tutorial (the second in the series) focusing on using the methods to create a simple loader application.

As its name suggests, a file loading program (or a resource loading program, to express the concept more accurately), is simply a PHP module that takes care of including, usually via its set of "include()/require() native functions, files that are required by an application to make it work as expected. [...] It's worthwhile to mention, however, that it was necessary to create an instance of the aforementioned class to load a determined file. This is a process that can be completely avoided in terms of good coding habits. But how can this be achieved? Well, it's feasible to statically call the class's load()" method, preventing its unwanted instantiation.

The code examples of the simple loader class (a require_once wrapped in a try/catch) and a usage example.

In this first part of a new series in application development, DevShed looks at building a loader for various resources inside your app.

Loading sources on the fly is one of the most common tasks that PHP programmers have to tackle during the development of web applications. This typical situation must be faced independently of the scale of the programs being created. This means a loader mechanism must be developed.

Their basic loader class uses a call to a load() method to do two things - check to ensure that a file exists and, if it does, include it (technically a require_once). They also put a bit of exception handling around it to help catch any errors thrown on the include.

On the PHP 10.0 blog, Stas does a little benchmarking of a big part of each request to a Zend Framework application - the Loader.

On Zend Framework lists there was a topic raised about performance impact of Zend_Loader component, which is used for - no surprise here! - loading classes, including autoloading, etc. Some folks thought that since Zend_Loader is executing some code before actual loading the required file, it must cost something. And it makes sense. However, how much does it cost?

He uses a set of scripts he developed to compare the bytecode caches of the requests both with and without the caching turned on. He ran the tests on a PHP 5.2 and PHP 5.3 installs with the lower (better) numbers coming from the latter in requests per second. He highly recommends turning this caching on on your system if you haven't already.

In a continuation of their "wishlist" series of posts for PHP6, Stephan Schmidt has postted this new item today taking about something he wishes PHP could do - initialize a property when defining an object.

But how could this be solved, when you never create an instance of Foo but only use static method calls?

I propose a new feature, we implemented in the Stubbles class loader and has been shamelessly ripped from the XP framework. If you need to initialize some properties with objects and are developing with Stubbles, you only need to implement a method called __static() in your class. If your class is loaded by the Stubbles class loader, it will check, whether this method has been implemented and call it. As every class is only loaded once, this enables you to add code to your class, that is also only executed once, if the class is imported into your application.

His solution allows for the creation of such objects with little more than the use of a __static call that could get the object and change the property defined on it.

Rob Allen bids a fond farewell to a part of the Zend Framework that's been there since the beginning - the Zend.php file and all of its associated classes.

This is good news as the Zend class was schizophrenic and provided functions responsible for file loading, registry, debugging and version information! Another side effect is that the entire Zend Framework is stored within the Zend directory making those who use svn:externals on their lib directory happier.

He mentions some of the other classes that have replaced it including the Zend_Loader and Zend_debug components) and changes to the Zend_Filter component too. Rob has also updated his tutorial to match this latest version for those just starting out.

When it comes to protecting your code, you definitely want to find the right product for your needs. Finding the information on all of the encoders out there can be a task in itself, though. Fortunately, EncoderCompare.com has been created to give you a quick and easy reference.

Whilst we would always recommend the use of the ionCube Encoder product to protect your PHP source code when distributing your product to customers and users, there are several other products available to choose from.

To help with this, we have launched a comparison website which lists the available encoders and compares their features. The feature set is standardised so that it is possible to compare like for like in a clear manner.

Currently, there's fifteen encoders listed with all of their stats - protection types, restrictions available, what OSes it has loaders for, the availability of licensing, and the pricing. There's links to get more specific information on each as well.