Recently I needed to process a huge array of data and because of PHP's somewhat inefficient variables and especially arrays that was resulting in "out of memory" errors. However, I couldn't use any other tools than PHP so was forced to come up with a solution implementation in it. Here is how I solved it using principles from functional languages.

He gives an example using Haskell to generate a Fibonacci sequence using its built-in lazy evaluation abilities. Unfortunately, PHP doesn't have such a thing built in, so he tries the next best thing - Iterators. He caries the idea over to the database side too, recommending fetch() in a loop over fetchAll() and some effective joins.

In the case of PHP 5, which is better suited for developing web-based programs, there are two complementary design patterns that can be of great help in building faster and more reliable applications. Of course, as this article's title suggests, I'm talking about the lazy and eager loading patterns. Despite their rather funny names, they are pretty easy to implement in PHP 5-controlled environments.

To illustrate, they've created a sample class that uses a few class properties and a __toString method to return the values.

Having been a PHP programmer for more than a decade, I've come to realize that many of my fellow PHP programmers seem to have a misplaced notion of what being "lazy" is really all about. [...] Suddenly the Web developer was facing so much more than validating user input and connecting to a database [and] the need to be a lazy programmer was more important than ever.

He covers a lot of the basics of frameworks with a focus on the Zend Framework (because of familiarity) - configuration, data validation tools, database connections, display helpers and the inclusion of third-party plugins.

Lazy loading is the capability of performing a expensive operation on demand, only when it reveals necessary from a client request. [...] In Doctrine 2 I made some architectural choices implementing the proxy approach, which substitute a subclassing object to every association which is not eager-loaded.

There's two main places you can see these differences - in the one/many to one associations dynamic proxies and collection interface.

What is lazy loading? A practice in object/relational mapping which simulate the presence of the whole object graph in memory. There is some techniques for produce this illusion that I explain here. [...] The main problem is that we cannot load all the object graph, because it will not fit in the memory of the server and it will take much time to build, depending on the size of the database. Nor we can load an arbitrary subset of it.

His solution is to use the proxy design pattern to create an interface allowing only the first level of information to be loaded by default. After that, each of the sub-levels have what they need to load themselves and the data that might be needed inside.

It's not that Andrei is wrong in his admonition. Far from it! For reasons that I don't quite care to know, there are caching and lookup optimizations that APC cannot do when it has to switch context to run __autoload.

They did see a performance boost from the code rewrite it took to make this happen but, since not everyone can take the time to optimize their code like this, he also suggests another way (as written up by Brian Shire). It uses two settings for APC in your php.ini file and the latest versions of PHP 5.3 & APC along with this patch to make them work.

In short, every test you write requires that you setup the test environment, create a scenario for possible failure, add an assertion, and then ensure the source code makes that assertion pass. This requires code - sometimes a lot of code. So adding multiple assertions to each test minimizes the work needed to write tests, since using multiple assertions takes advantage of existing code to avoid writing new stuff to clutter your test classes. It can also help to tackle multiple but related results in the same test.

He gives brief examples of both instances and some of the problems associated with them. Multiple assertions, while nice for fine tuning the results of the testing, can also confuse since, if one assertion fails, the whole test fails too. The other end of the spectrum is a problem too - writing tests that don't do enough to really check the information passed in. These shallow tests can lead to issues down the line if unanticipated data might come along.

Really, its all about finding that "sweet spot" in developing tests - not too much, not too little - and keeping it simple while not missing out on assertions that need to be made.

The previous update (0.9.26) updated the utility with an improved randomness fixing a few issues with an ini setting and the uploadprogress extension as well as adding in a few new settings and updates to the randomizing functions that come included in PHP.

The 0.9.27 update (the most current) updates the patch with a lazy loading change that allows it to work correctly on systems that have it disabled by default (causing the previous patch to not work).

You can grab this latest release, 0.9.27, from the suhosin website.

I used the magic method __get() to load the images into the [Product] object when they were needed. __get() is called whenever something tries to access a variable that is not set or publically accessible, so basically I used that to load the images whenever some other piece of code tried to access Product::images.

He includes a quick bit of code that fires off an internal private method for the class that loads up the images. In his example, if they're already loaded, it never gets called.

This tip is useful to "lazy" developers who do not even think about variable names. They may prefer magic names like ${0} and 0 is good enough variable name, why not...

His list consists of:

• Use || (or) and && (and) operations instead of if.
• Use ternary operator.
• Use for instead of while.
• In some cases PHP requires you to create a variable. [...] To handle all these situation you can create a set of small functions which shortcuts frequently used operations.
• Explore the language you use.
• When it is better to write more and then read the code easily, do not be lazy.

Check out Vidyut Luther's response to Alex's comments as well as one from Richard Heyes.