Mark Baker has posted a tutorial to his site showing how to use closure binding as an alternative to "use" when calling closures in your PHP application.

As a general rule when creating a Closure, arguments are passed when the function is called, but “use” variables (I’m sure that they have a formal name, but have no idea what it might be, so I just refer to them as “use” variables because they’re passed to the Closure through a “use” clause) are fixed as the value that they already contain when the Closure is defined, and the variables themselves must already exist within that scope

[...] Of course, the drawback of this approach is that when we need to change the price minimum and maximum values for filtering, they’re hard-coded in the callback.

He talks about the limits this imposes on calling the closure (ex: can't easily add addition params) and how the values have to already exist before the closure can be called. He points out that calling the variables by reference can help somewhat but it still comes with some of the same baggage. He then shows how to use object binding for a closure to handle the same kind of "min" and "max" by working around it with a closure bound internally to an object and called via a public method.

The Dotdev.co blog has posted a tutorial for the Laravel users out there with the goal of helping you understand the Laravel service container, a key part of the framework's functionality and an extensible feature you can adapt to some of your own needs.

Learning how to build an application with Laravel is not just about learning to use the different classes and components within the framework, it is not about remembering all artisan commands or remembering all helper functions (we have Google for that). Learning to code with Laravel is learning the philosophy of Laravel, its elegance and its beautiful syntax. I personally feel it is an art and a craft (its not a coincidence that Laravel developers are sometimes referred to as Web artisans). This is true for any other framework as well.

A major part of Laravel’s philosophy is the Service Container or IoC container. As a Laravel developer, understanding and using the Service Container properly is a crucial part in mastering your craft, as it is the core of any Laravel application.

The post starts with some of the basics about the container and how objects/instances are bound to it. They give an example of binding a FooService class in the "register" methods of providers. A code example is also included showing how to use the service you previously bound. There's also a description of binding interfaces in the IoC, making it easier for custom classes to resolve interfaces when they're implemented. The post wraps up with a bit covering the resolving of dependencies and the code you'll need to set them up.

Marco Pivetta has posted about an interesting trick you can do with closures in PHP related to accessing private properties inside classes.

A couple of weeks ago I was working on a very tricky issue on ProxyManager. The problem is simple: instantiating ReflectionClass or ReflectionProperty is slow, and by slow, I mean really slow! The reason for this research is that I'm trying to optimize a "hydrator" to work with larger data-sets by still keeping a low initialization overhead. PHP 5.4 comes with a new API for Closures, which is Closure#bind(). Closure#bind() basically allows you to get an instance of a closure with the scope of a given object or class. Neat! That's basically like adding APIs to existing objects! Let's break some OOP encapsulation to fit our needs.

He shows how to use this "bind" feature to reach into an object, in this case a "Kitchen", and extract the value of an internal, private property. He also talks some about the performance of this method versus the more typical use of Reflection. He includes two other quick examples too - accessing the same private properties by reference and an abstracted "property reader" closure that uses the bind trick on any object.

On the BinaryTides.com site there's a recent tutorial showing you how to effectively use sockets in your PHP applications, complete with incoming and outgoing examples.

This is a quick guide/tutorial to learning socket programming in php. Socket programming php is very similar to C. Most functions are similar in names, parameters and output. However unlike C, socket programs written in php would run the same way on any os that has php installed. So the code does not need any platform specific changes (mostly).

They start with the basics - creating a socket, connecting to a server and sending out information over the connection. They also include the code examples showing how to pull in data from the socket. Their example socket is set up to be a simplistic web server, returning data according to the standards for a normal GET request. They make a mini-server out of it, getting to to accept requests on a bound socket.

Davey Shafik has posted about an interesting find with closures in PHP revolving around an update to add "$this" access inside the closure.

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).

In a new post to his blog Till Klampaeckel looks at something the Zend Framework's Zend_Db component dosen't seem to support - an "IN" on a fetchAll - and how he worked around it.

The IN-clause is only supported when I wrap my statement with Zend_Db_Select, which is something I rarely do. Part of the reason is that I still don't feel comfortable writing my SQL in a DSL which doesn't really do anything besides wrapping a string into an object and IMHO it doesn't add to readability either. And the other reason is that I don't plan to run this import against any other database than MySQL. Which is why I don't see the need for abstraction either.

He shows some failing code where the IN isn't populated correctly when an array is passed in and the warnings that come with it. He solution's pretty simple, though - rewrite the query string before sending it with the correct number of bind locations ("?") for the number of parameters. In the comments, other approaches are suggested including using a simple select() call or tricking the bindings with a special kind of array.

Gonzalo Ayuso has posted the results of some performance testing he did with bind parameters in a PDO-based request for his application.

Some months ago a work mate asked me for the differences between using bind variables versus executing the SQL statement directly as a string throughout a PDO connection. Basically the work-flow of almost all database drivers is the same: Prepare statement, execute and fetch results. [...] What's the best one? Both method work properly. The difference is how databases manage the operation internally.

He gives two code examples, one with the bind parameters and one without, and the benchmark code he used to generate his statistics. It uses a PDO connection to execute several statements in a row both with bind parameters and without, measuring the time (with microtime) and outputting the results. His results show that while the simple update is faster, the bind parameter method has the added benefit of reusability for multiple queries.

Brian Swan has a new post today looking at one way you can protect your web application from potential attack - preventing SQL injection by filtering input.

How to prevent SQL injection in PHP scripts is probably a topic that doesn’t need anything more written about it. [...] However, it is important to have fresh information for new Web developers and I don’t necessarily agree with some of the most common suggestions for preventing SQL injection. [...] So, this will be yet another post about preventing SQL injection, but I will offer my 2 cents about what I think is the right way to prevent it.

He explains SQL injections for those that are unsure on the concept with a basic form example and what he thinks is a better way to prevent it than just trying to escape the SQL - bound parameters. These allow you to both filter and protect your application from any would-be attacks that might come your way. He is, of course, using SQL Server so the parameter binding is included in the database functionality. Other databases might have to use something like PDO to accomplish the same kind of thing.

In a recent post to his blog, Davey Shafik looks at solving something that has "always bugged him about using prepared statements" - getting the actual query it used back out.

Today, a friend asking me if it was possible to get a prepared statement back from PDO with the values placeholders replaced, finally caught me in a moment where I could do something about it. I wrote a thin PDO wrapper class that will [imperfectly, I'm sure] return the completed query.

His class (complete code included in the post) includes a getSQL() method that hands you back the results of your bound parameter query as a string. A few examples of its use are also included.

On the SitePoint PHP Blog today, Troels Knak-Nielsen has written up a post concerning the current state of functional programming in PHP.

With the rise of Javascript, and languages like Python and Ruby, functional programming is becoming more mainstream. Even Java seems to be getting closures in the next version, so does this leave PHP lacking behind or is there an unrealized potential hidden within?

He looks at a few different aspects of functional programming and sees how well PHP fits into them (like dynamic dispatch, binding a variable to a function and an implementation of currying for a function). This last option is the only "true" functional feature that PHP can realistically handle.