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.

Frustrated with the lack of something simple (like mysql_fetch_assoc) in the new mysqli extension, this new function was created an posted about on the Internet Super Hero blog - mysqli_stmt_get_results.

By help of the new function, you can create a mysqli_result object from a statement that returns data (SELECT and other - version dependent!). Then you can use the mysqli_result object to process the returned data: fetch results, access meta data - all you can also do using a mysqli_result object returned by mysqli_query().

Included in the post are a few code examples showing the simplicity of the function and how it can still be used with the standard mysql_* functions to grab the results.

In a new post today, Maggie Nelson starts with the wrong way to do something - passing an array from PHP to a database - and works backward to make it all right.

It would be really useful to have an easy way to pass arrays as bound parameters to queries or procedures from PHP. This would be especially useful if you're letting Oracle handle most of your data manipulating (as you should).

She includes an example of how she's like it to work. Sadly, it doesn't but there are some ways that a developer could get close. Here's her process:

• No queries in loops, please!
• In the ideal world...
• Put all your DML in stored procedures.
• str2tbl
• The list_pkg package
• list_pkg in your procedure
• list_pkg in your PHP
• Leveraging list_pkg

The list_pkg is based around this article from AskTom.

http://www.phpdeveloper.org/form/view/type/addnews PHPDeveloper.org: PHP News, Views, and Community In a new post Paul Jones points out some of the new behaviors that the extension is showing in the latest of the PHP 5 seres (version 5.2).

He starts with a code example that would work with a previous version of PHP/PDO that would allow for the binding of a single value to multiple places in the SQL statement. But:

Sadly, this is no longer the case in PHP 5.2.1. For valid reasons of security and stability in memory handling, as noted to me by Wez Furlong, the above behavior is no longer supported. That is, you cannot bind a single parameter or value to multiple identical placeholders in a statement. If you try it, PDO will throw an exception or raise an error, and will not execute the query. In short, you now need to match exactly the number of bound parameters or values with the number of placeholders.

Unfortunately, this is used quite often in Paul's Solar framework, so an update to the Solar_Sql_Adapter::query() method has had to been made to allow for the binding of multiple items automatically. It works by incrementing the bind location (like ":foo") with numbers at the end - simple and effective - and you can still pass an array to it and have it automagically work.