Nicolas Grekas has submitted about a new tool he's developed to "represent faithfully any PHP variable as complex as it is" - Patchwork-Doc (related to his Patchwork PHP framework).

The JSON format on which it rests guarantees maximum interoperability while ensuring good readability. The implementation done in the JsonDumper class operates all potentialities of the representation while providing maximum latitude to the developer to exploit its ability as desired, both in term of exposure of internal class mechanism for specialization and in terms of custom use, thanks to the callbacks that allow to intercept the JSON line by line and to adjust the dumping of objects or resources according to their type.

It isn't required to use the framework to use this tool, however. You can see an example of the output format in this example on the project's github page, complete with a guide to some of the advantages and disadvantages of some of the current, more common methods of output. Several types are included in the example including simple string/integer values, objects, classes, stream resources and the results of variable casting.

Gonzalo Ayuso has a new post to his blog today talking about a regular expression-laden script he's some up with to reflect over a PHP file and pull out the document's comments (PHPDoc-style).

I want to parse PHPDoc code. Let me explain a little bit what I want to do. Imagine a dummy function documented with PHPDoc. [...] PHP has a great reflection API, but as at least in the current PHP version (as far as I know) we only can get the PHPDoc as a string, without parse it. I need to get the parameters and the type of them with reflection. [...] But the type is different.

His script (based loosely on a bit of a component from the Zend Framework) parses the file and its comments and grabs the variable types from the PHPDoc blocks on each method and associates them.

If you're looking for a more mature solution than just this script, take a look at Docblox, a PHP 5.3 documentation generator.

Derick Rethans has a new post to his blog today looking at a way you can dig inside of a variable that might be causing you trouble with the help of the debug_zval_dump method - a PHP function that dumps a string representation of an internal zend value directly to the standard output method (usually an "echo").

The internal representation of a PHP variable container (called zval), contains the type and value of a variable, but also whether it is a reference and what its refcount is. Due to PHP's copy-on-write policy, one specific zval container can be used by multiple variables at the same time as we will see in a bit.

He talks about what the "refcount" field of a variable means and some simple examples showing a single reference, more than one symbols and how PHP handles a "split upon assignment". He also mentions Xdebug's method xdebug_debug_zval that takes in a variable name rather than the variable itself.

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.

Over on Reddit.com there's an interesting post (yes, despite some of the comments made on it) about variable variables that turns into a detailed look at PHP variable handling as based around "$".

OK, here's the thing: [variable variables are] only the entrance of the rabbit hole. [...] The first thing to understand is what $ is. $ is actually a shorthand for ${} and means "return the value of the variable whose name is contained in this".

The response goes on to talk about variable names as strings, a few string handling tricks that can be used when referencing them and how this works with objects too. Things get a bit more complicated when they start adding in more levels of "variable" and evaluations based on random results. Not overly useful information for the casual developer, but interesting to know none the less.

Sameer Borate as a new post to his blog today looking at some of the quirks he's found when dealing with the $_POST superglobal in PHP.

A little quirk of PHP $_POST var I encountered while fixing a Salesforce web-to-Lead bug. A Wordpress site was using a form to submit user requests to the Salesforce web-service. The form that submitted the data had the following fields along with the others. The problem was with the multi-select field, only the last value selected in the multi-select was getting captured.

He investigated and found that his code was echoing out all of the values, but wasn't using the "field_name[]" notation with the square brackets to send back multiple values to PHP. Changing this and trying again, he noticed it still wasn't working as expected (with Salesforce). He figured out they're using "raw" versus "cooked" handling of the POSTed variables. Check out the rest of his post to find out what that means.

Derick Rethans is republishing an article series he wrote (originally for php|architect) about the garbage collection that is included with the PHP 5.3 releases. He kicks off the series with this first post introducing internal variable handling.

Before we start with the intricate details of PHP's new GC engine I will explain why it is actually needed. This, combined with an introduction how PHP deals with variables in general is explained in this first part of the column. The second part will cover the solution and some notes on the GC mechanism itself, and the third part covers some implications of the GC mechanism, as well as some benchmarks. But now first on to the introduction.

He introduces the concept of a "zval" - the container PHP uses internally to handle variables (along with its "is_ref" and "refcount" to tell the interpreter if it's a reference or not). He also shows how these relate to the variables you set in your applications as well as a mention of the xdebug_debug_zval function of XDebug to show how it's handled behind the scenes. He also shows how references are handled with accompanying images to show the flow. If you'd like more information on variable handling, Derick points to this article for more detail.

Johannes Schluter has a new post to his blog on another PHP internals related topic - hashtables.

While preparing my "PHP Under The Hood" talk for the Dutch PHP Conference there was a question on IRC about extension_loaded() being faster than function_exists(), which might be strange as both of them are simple hash lookups and a hash lookup is said to be O(1). I started to write some slides for it but figured out that I won't have the time to go through it during that presentation, so I'm doing this now.

He talks about array storage (a "real" array), numeric and string-based keys, the internals of how each is stored and how the differences make the one function faster than the other (hint: it's all about collisions).

To reinforce a point he's made before (references in PHP are bad) Johannes Schluter has posted an example to his blog of a specific instance that causes an (expected) issue with references and foreach loops.

Now there is one use case which leads to an, at first, unexpected behavior which I didn't see as a real live issue when I stumbled over it at first, but then there were a few bug reports about it and recently a friend asked me about it ... so here it goes.

He show a code snippet of looping over an array with two foreaches and a print_r that shows the bug - the array changed from the original for no clearly apparent reason. To understand why this happens, he goes into detail on how variables are handled - complete with graphs.

Continuing on in his refactoring series (part 1 & part 2) Sameer has posted part three - a method of replacing temporary variables with calls to other methods.

Temporary variables are a integral part of any code. But a splattering of the same all over can make your code hard to understand or modify. Replace temp with query is a refactoring method where you replace temp variable expressions with methods. This method is often also required before you use the Extract Method refactoring.

In his example, he takes a variable inside a current method (base_price) and replaces it with a method call by the same name resulting in a more reusable format other methods can call rather than just computing the value themselves.