I'm trying to do some remote debugging with PHPUnit on a remote system. I was following the rules I had written about in a previous article but for some reason I could not get path mapping to work. So I figured I'd ping the Studio lead developer because as soon as I did that I'd get it to work. Well, that's what happened.

His fix comes in the form of setting a command-line parameter, QUERY_STRING, with the correct parameter order so the paths will get mapped back to the correct project. This parameter is a URL-encoded set of parameters that do things like start the debugging, set up the hostname for the debugger to point to and map the "original URL" back to your choice of values.

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.

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.

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.

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.

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.

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.

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.

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

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.