We started the study of PHP magic methods by learning about __get() magic method. [...] PHP is loosely typed language and same variable can be used or referred as string, number or object. The __toString() method is called when the code attempts to treat an object like a string. This function does not accept any arguments and should return a string.

Some quick code is included showing how it works - returning a combined string made from two private class properties when the object ($obj) is echoed out. They also show multiple ways of using the method in both pre- and post-PHP 5.2.

Sometimes the most crucial, basic piece of information can seem so hard to find. For example, suppose you wanted to find out what version of PHP your remote webhost provides to shared hosting users? What would you do? [...] For development purposes it can be helpful having phpinfo() available, but on a live shared host, you may discover as I did recently that it is no longer available; your host may have disabled it.

She includes three other ways you can use to get the version of PHP you're working with:

• If you have command line access, running "php -v"
• Using the phpversion function (or PHP_VERSION constant)
• Appending a certain value to the URL (only works in some cases)

Static helpers seem to be a great idea at first glance, as they're reusable components that don't require any kind of expensive instantiation for doing common tasks [...]. But the sad and unavoidable truth is in many cases they're simply wrappers for procedural code, which has been elegantly hidden behind a "class" construct. So what's wrong with this? Well, even in the most harmless situations, when you use a static helper that produces a deterministic output, you're actually throwing away the advantages that OOP provides.

To illustrate, they create a basic validation class that can check for things like valid emails, float values, integers and URLs using PHP's filter_var function. They point out that the class is difficult to extend and that it is doing too many things to be correctly considered a "piece" of functionality. To correct the problem, they opt for a different approach - an abstract class acting as an interface to structure custom validators against. This provides set/get methods for things like the error message and value to evaluate. The implementation of the validators on top of this class is coming in the next part of the series.

The Factory Method pattern is a design pattern used to define a runtime interface for creating an object. It's called a factory because it creates various types of objects without necessarily knowing what kind of object it creates or how to create it.

Code is included showing how to make creating "Product_*" classes as simple as calling a "build()" method with the type. A slightly more complex situation is also included - building factories inside of factory methods. For more about the Factory design pattern, check out its Wikipedia page (that includes some common uses and some pitfalls to watch out for).

While migrating pastium over to MongoDB (from CouchDB), I found [a] snippet in the routes.php file [that makes it so] when the user enters the application via the root url (/), he instantly gets redirected to /pastes/add (or a different URL if you have custom routes configured). This may seem ok at first, but there's a problem. It doesn't take URLs into account that don't live directly under the document root.

The snippet he references and others showing how to correct the issue are included - replacing the location array controller/action information with the static class information for the route in a match() call. For more information on the routing in Lithium, see these manual pages.

The outcome is this little library making it much easier to generate a proxy of your system under test (SUT). Another thought on this library was, that it should be very easy to use if you know the way to mock classes and methods in PHPUnit. Proxy-object has almost the same API, but does not change the behavior of the proxied class/method. The only purpose is to expose hidden methods and members.

The scripts, found on github, give you a simple way to define a proxy over a given class' functionality and define methods/member variables to be exposed. He includes two code examples, one of each type. There's also an example of making the proxy object without calling the constructor, useful in certain cases when the initialization of the object doesn't need to happen.

You can also find out more about the usage of this tool in this new post to Bastian's blog.

A small gotcha I recently ran into: If you use typehinting, PHP never checks that the class your typehint specifies actually exists!

He includes simple examples that define the class type hint as some random string and PHP never throws an error for it. He also notes that it's even worse when dealing with namespaces - how it handles exceptions locally unless you specify otherwise. Of course, these "features" can be put to good use in the right situations, but they can be confusing for a developer without a keen eye.

Of the other patterns mentioned, the one closest to the Proxy is the Decorator. In the case of a Decorator, the focus is on adding functionality to an existing object -- for instance, adding methods, processing input before delegating to the target object, or filtering the return of a method from a target object.

Proxies stand in for objects and have several benefits for your application that may or may not need all of the overhead a full object could cause. Matthew focuses on one benefit in particular - consuming and controlling access to another object. He sets up a problem of wanting to use properties/methods on objects that aren't exposed directly (like a protected method). His solution is a proxy layer class on top of the original object. He includes a few "gotchas" to look out for when using this technique including overwriting all necessary methods and copying over all of the needed properties.

I wrote a couple tests for a small CouchDB access wrapper today. But when I wrote the implementation itself, I realized that my class setup depends on an actual CouchDB server being available and here my journey began.

It was his first experience trying to mock out parts of a class, and he found it a bit difficult to use even after reading this article from Sebastian Bergmann. He ended up, as a first solution, making a "fake" (a term from Ruby testing) that just returned the basic JSON string of an error. Thanks to comments on the post, though, he was able to come up with a more correct solution using getMock() to create a stub and apply an expects() to his "makeRequest" method.

Zend Framework has own Reflection extension. It is mostly build upon genuine PHP Reflection API and extends existing features. The completely new Zend_Reflection module feature is introspection of docBlock tags.

He includes two code examples using this component of the framework - grabbing the docblock off of a specific method (and even how to grab specific tags from inside it) and how to grab the body content out of a given method, with or without the docblock attached.