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.

In our last PHP Ad Tracker lesson, we constructed the database tables for our ad banner application. Now we are ready to construct the data object that will hold the variables and functions that will display, add, edit and delete the data in those tables.

They cover each of the variables they'll be using with a summary of what they're used for as well as the various functions to be defined and what they'll return. Following this, they get into the actual development - creating an "ads" class and defining the methods to get the current ad count, get the number of clients and pull the actual client/ad data.

Mocking objects in unit tests is pretty straightforward as every object used in a test case is usually created in a scope of one test class. In functional tests it's a bit harder since we either don't have full control over objects being created or it's simply too laborious to mock half the framework. [...] We're getting the service from a container [in the example] and calling a method which should send a lead. The problem is we don't want to actually call an API while executing Behat scenarios.

Rather than hitting up the API for each test, he opts to create mock objects and results with the tools Mockery has to offer. He gives code for a "is API available" method that either returns a valid container or a mocked object, depending on how it was called.

However, it didn't stop there; there was also the addition of Closure::bind() and Closure->bindTo(). These methods are identical except one is a static method into which the closure is passed, the second an instance method on the closure itself. These methods both take two arguments (on top of the closure for the static version): $newthis and $newscope. What this means is that unlike the regular object model the concept of $this and lexical scope (what is in scope for the function with regards to private/protected methods inside objects) are completely separated.

He also mentions that you can change the "$this" to a different object (complex) or swapping out the object the closure is bound to while keeping "$this" the same (simpler). He mentions that it could be useful for unit testing but can have its drawbacks. He's included code to illustrate the breakage it can cause in the PHP OOP model (with an explanation).

I think the fact that we have $_POST and $_GET lulls some of us into the false sense that we should have $_PUT and $_DELETE objects, since that would map to the commonly-desired set of HTTP verbs that REST likes to use. But what should be inside those things, or should we be moving towards a more Pythonesque solution where a Request object, as part of core or via a only-really-for-the-brave- PECL extension?

He mentions opinions from other PHP community members (Laura Thompson and Elizabeth Smith) and a bit about what he (and I'm sure other developers) are looking for in a more full-featured request/response handling feature.

Using the memory/temporary stream provided by php:// stream wrapper you can create a stream with read and write access directly to RAM or to a temporary file [using "php://memory"]. This gives you the possibilty to write unit tests that does not rely on a specific file, resource or stream, but rather on data provided by the test itself.

There's no specific code examples here, but you can refer to the stream wrappers section of the PHP manual for more details on this and other handy built-in streams. Once created, it can then be used just as any other stream resource can. This could be useful to provide mocks in your testing, replacing any other stream-able resource with a "memory" or "temp" placeholder.

Rackspace provides a Software Development Kit (SDK) for multiple programming languages. They store their PHP SDK on GitHub. The PHP SDK requires PHP 5 with the following modules: cURL, FileInfo and mbstring. In this tutorial we are going to review use of the PHP SDK with CloudFiles. Not all parts of the API will be covered but you will get a great start.

Code is included showing how to make the connection, work with containers, pushing content out to a CDN, object handling and a few other handy tips (and API info) to help you along your way.

At the end of the script the interpreter frees the memory. Actually every object has a built-in destructor, just like it has built-in constructor. So even we don't define it explicitly, the object has its destructor. Usually this destructor is executed at the end of the script, or whenever the object isn't needed anymore. This can happen, for instance, at the end of a function body. Now if we call the destructor explicitly, which as I said I've seen many times, here's what happen. As you can see calling the destructor explicitly doesn't destroy the object. So the question is...how to destroy an object before the script stops?

He points out that one way to "destroy" an object is to null it out and remove the structure from memory. This is tricky, though, because a clone of the object will still exist in memory, just not the original.

Recently I did a lot of Test Driven Development on my Symfony2 bundle. I used PHPUnit's built-in mocks and stubs for many projects, so I took it again. But while I was working on mocking Symfony2 core objects I found those mocks very uncomfortable in use. I tried Mockery and it saved my day. Let's see how to get it working with Symfony2 and how it kicks ass!

He shows how to get things set up - adding Mockery to the dependencies file (deps), getting the latest version from their git repository and an example mock method that shows the difference in mocking the Doctrine2 entity manager - PHPUnit vs Mockery.

For the people who read PHP's NEWS file, it's no surprise - but for all who don't here's is probably one of the biggest features of PHP 5.4: Closure Object Support is back. For me it's something I missed the most, when Closures were introduced in PHP 5.3. So I'm very happy, that's finally here (or back). I'm going to tell you about the rocky road which closure object binding support had and show you some simple use cases for it.

The functionality, based on this RFC, lets you more correctly bind closures to objects instead of having to pass the objects into the closure at create time. He includes an example from a Silex framework application and an example that refactors a helper method as a part of rendering a simple template.