On the Ibuildings blog today Lorenzo Alberton takes a look at the Zend Framework, specifically as to how it can mimic regular HTTP calls with the built-in components.

One of the unit testing best practices suggests to break dependencies, so you can test each component separately. The first problem that arises when you want to test controllers might be having a tighter control over the HTTP Request and Response objects.

This problem is overcome with the Zend_Test_PHPUnit_ControllerTestCase. The second problem it with calls to external resources (like models/databases or web services). This is the prime focus of the post and seceral blocks of code are included to make a class to emulate the HTTP responses you might get back from the service.

In a recent post to his blog Dhiraj Patra looks at the caching functionality that PEAR has to offer via the PEAR Cache package.

Caching is currently a hot topic in the PHP world. Because PHP produces dynamic web pages, scripts must be run and results must be calculated each time a web page is requested, regardless if the results are the same each time. In addition, PHP compiles the script every time it is requested. [...] PEAR's Cache package offers a framework for the caching of dynamic content, database queries, and PHP function calls.

He talks a bit about what kind of methods are included with the package and shows examples of how it works for function call caching, caching the output from the script execution and how to implement your own custom caching extension of the main code to make it even more flexible.

Stefan Mischook has a (very) basic introduction video posted showing how to call functions/methods from another class outside the one you're currently using.

Recently I was asked by someone how they could call a function found in one class, in another. This may seem like basic stuff to those of us who know...but please keep in mind, at one time, none of us knew anything!

You can check out the video here. Be sure to check out more of the great videos he's created too on topics ranging from MVC frameworks to a beginner's guide to PHP.

Chris Hartjes has posted again about the "rebirth" of a Zend Framework component he's worked on - the Zend_Service_Audioscrobbler.

So, dear readers, I received some nice emails and comments from those you have used Zend_Service_Audioscrobbler, along with having a nice email conversation with Wil Sinclair from Zend.

He still wants to "rip things up and start over", but has decided on a slightly different route - mapping the older function calls to the new ones via a __call catch and including a message stating that the older function call would be deprecated.

In a new post to his blog today, John Coggeshall comments on some thoughts from Alan Knowles about a method for making PHP obsolete.

Alan, I think you were smoking way too much PHP when you wrote this post.. This in particular really surprised me to hear you say [that a module that made mysql stored procedure calls based on a URL and returned JSON could make PHP obsolete]. While I do understand the concept your explaining, I simply can't see how the model is practical at all for two big reasons.

His reasons involve not having a business case where an entire application is right there for the user to download and that its an insecure method for running an app.

Larry Garfield has put together some benchmarks based around a request he had from other developers (the "performance czars") as to how the magic functions in PHP5 would perform in the new environment.

Already, there is talk of how, and if, to leverage PHP 5's object handling now that we don't need to deal with the weirdness of PHP 4's object model. Of course, because it's Drupal, our army of performance czars want to know just what the cost is for object handling, and especially advanced object magic like __get(), __call(), the ArrayAccess interface, and so forth.

He an his tests on a Thinkpad (Intel Core2 Duo 2.2Ghz) running Kubuntu and PHP 5.2.3. They were run two million times benchmarking the different methods for:

• function calls
• __call
• __get
• __set
• iterators (array)
• inheritance
• composition

His results are listed at the end of the post.

While working with some code of his, Travis Swicegood noticed something odd when he tried to work with Exceptions in a __destruct call:

You must be doing something right when you can send PHP into a tail spin. That or the code you're trying to do is just evil. Turns out __destruct() and __call() don't play well together in 5.2.4 if, and only if, you create an instance of an object without assigning it.

The official (and verified) bug over on the bugs.php.net site gets into more detail on it including a code block that illustrates the point as simply as possible.

In the example I blogged about, __destruct() actually wants to catch any exceptions so it can create meaningful output based on the Exceptions that were generated. In that case, __destruct() would have returned peacefully. [...] At any rate, my take on that would be that would still be that if __destruct() is finished and an exception is still present, then there's an error. Otherwise, how would you handle things such as PDOExceptions thrown during DB clean-up?

Jeff Moore mentions a "sweet improvement" he noticed when comparing the error message from a PHP4 script to a PHP5 one - the location reported for error mesages.

Sometimes its the little things that make a difference.

His sample script (a function call without the argument needed) errors on the location of the function definition in PHP4, but happily PHP5 recognized the problem for what it's worth and echoed out the location of the call to that function instead for the line number.

One more reason to ditch PHP 4 and go php 5.

Exploration in a language is always a good thing and, in this new post to his blog, Joshua Thompson approaches a method of programming familiar to Javascript users - Prototype-based programming.

The basic idea is that functions can be added to classes dynamically. In Javascript functions can be added to a static class (using prototype) and it will be added to all instances of the class, or they can be added to a specific instance and only be added to that instance.

The rest of the post is all about the code - a Prototype class that sets up the __get, __call, __set magic functions and a prototype() method and isCallable method (to check if a function exists). In his example, he creates three test classes that he adds functions to, including one that inherits from one of the other test classes (and not just the Prototype class).

In the end, he uses it to call his custom "fun" methods, outputting various results based on the contents passed in.

DevShed is wrapping up their "Overloading in PHP" series today with this last part - "Overloading Classes in PHP5".

It's time to move on and continue exploring the subject, since there are still a few additional topics that need to be covered. So, what's comes next now? All right, in this last part of the series, I'll be explaining how to overload classes specifically in PHP 5, which offers native support for overloading class members and methods, without having to explicitly call the PHP built-in "overload()" function.

They look first at using the __get method to replace __set in their previous code to save data out to a file. Then, to illustrate even more enhanced functionality, they implement __get and __set at the same time in a class, using them to grab values and set values to properties. Finally, they throw __call into the mix, showing how to overload method calls too.