Derick Rethans has posted another article about Xdebug and some of the changes made in the most recent release, version 2.3. In his previous post he talked about the improvements to var_dump and in this one he shares updates to the xdebug_debug_zval handling.

xdebug_debug_zval() has been around for quite some time, to provide correct information about how PHP internally stores a variable. Unlike PHP's built in debug_zval_dump() function, it does not modify the variable information that it tries to show. This is because instead of passing in a variable, you pass in its name. Passing a variable into a function, can modify the various parameters that are associated with this variable, such as the is_ref and refcount fields.

He includes a bit of background about what the function is used for and then shows the difference it has in 2.3: the ability to handle nested data structures including property dereference support. He includes a few code examples showing the use of the function and the output it would generate for both an array and an object.

In his latest post Nikita Popov gives a detailed look at PHP's new hashtable implementation and what kinds of improvements it offers over the previous methods. The "hashtable" handling is how the language references array values created during the execution of a script.

About three years ago I wrote an article analyzing the memory usage of arrays in PHP 5. As part of the work on the upcoming PHP 7, large parts of the Zend Engine have been rewritten with a focus on smaller data structures requiring fewer allocations. In this article I will provide an overview of the new hashtable implementation and show why it is more efficient than the previous implementation.

He starts with an introduction to the concept of hashtables, describing them as "ordered dictionaries" of key/value pairs that (internally) reference values in an array. He looks at the old method PHP used to make these links and how the new version, with the help of zval handling, is different. He talks about how it handles the order of elements, does lookups and the introduction of "packed" and "empty" hashtables. He ends the post with a look at this new implementation's memory utilization and what kind of performance gains we can expect with its introduction in PHP7.

In his latest post Stanislav Malyshev looks at a RFC he's proposed to allow array keys to be objects including some of his thoughts behind the proposal and how he sees it being helpful to the language.

I'm going to put to vote soon another of my RFCs, namely one about "objects as keys". So, I want to outline the case for it here and address some criticisms and questions raised while discussing it.

He starts off by answering the "why" question, mentioning specially the introduction of things like GMP numbers and how, despite them seeming to work like numbers, other things can be done with them. He talks about how you'd use this functionality "the right way" and how that'd relate back to value objects. He answers a few other questions about the proposal including why it's better than just using __toString or spl_object_hash instead. He spends the rest of the post looking at some of the implementation problems, disadvantages and some of the possible names (function names) for the handling.

A common programming requirement is to match a string against a set of known strings. For example, let's say you were iterating over the words in a forum post and testing to see if a word is in a list of prohibited words. A common approach to this problem is to create an array of the known prohibited words and then use PHP's in_array() function to test if the string is found in the list. However, there's a simple optimization you can make to significantly improve the performance of the algorithm.

He includes two pieces of sample code - one showing the searching of an array using in_array and the other running an isset to locate a key. He points out that the in_array method is quite a bit slower than the hash (key) lookup and includes a benchmark script to prove it.The results are pretty clear, with the hash lookup coming in about 480% faster than the in_array. He also points out that as the size of the strings you're comparing grows, the performance of in_array drops even more.

In his latest postNikita Popov aims to make a case against the introduction of the "ifsetor" function to be introduced into the PHP language. This function takes in a variable to find and, if found returns it. If not, it doesn't produce an error (or warning).

Recently igorw wrote a blog post on how to traverse nested array structures with potentially non-existing keys without throwing notices. The current "idiomatic" way to do something like this, is to use isset() together with a ternary operator. [...] Someone on /r/PHP pointed out that there is an alternative approach to this problem, namely the use of an ifsetor function.

He goes on to talk about by-reference argument passing, why requesting an undefined array index doesn't really throw an error and how writes don't have the same issues as reads. He then gets into his own issues around the "ifsetor" function, namely:

Creation of dummy values

No notices for nested indices

Null values treated as non-existing

Default is always evaluated

By-reference passing often forces a copy

He summarizes most of the issues in one statement - "there is way too much by-ref magic involved". He then looks at some of the ways that this could be helped but opts instead for something more like "get_in" as proposed by Igor.

On the SitePoint PHP Blog a tutorial has been posted recently about having some fun with array interfaces via some of the functionality provided through the SPL (Standard PHP Library).

As a programmer who works with different languages every day, I find a lot of joy in learning how things are done differently in other languages and seeing if I can do the same in PHP. One thing I liked in particular in Python was how one can emulate features of native data types in custom classes. [...] I thought it would be nice if you could do the same in PHP on an instance of your custom classes and not only arrays. PHP lets us do this with array interfaces.

He illustrates his intent with some basic Python functionality and shows how to use various PHP interfaces to achieve a similar functionality. He talks about SPL interfaces like Countable, ArrayAccess and Iterator to make objects more useful in an array handling environment. His example uses the idea of a set of user's tweets (from Twitter) and shows the implementation of these three interfaces.

On the Leve.rs blog there's a recent post showing what they consider is the right way to work with arrays in PHP. It shows three things you can do to use PHP's own functionality to more correctly perform some common array operations.

More often than not, when PHP developers debug others' code, the majority of each method is taken up by array manipulations. Spending this much time on array manipulations is a huge hassle when trying to understand any given method. In order to speed up the debugging process, it's important to start writing array manipulations the correct way, first. Here are a few examples of code I have either written myself or had to fix in the past. It is time every PHP developer knows how to manipulate arrays properly!

Chris Hartjes, testing guru, has a post talking about using arrays in data providers for your unit tests. More specifically about some odd behavior one developer was seeing in their tests.

I was asked a question on Twitter by Tex Morgan about a problem he was having with PHPUnit data providers. He was trying to pass in some data and kept wondering why PHPUnit was serializing the data instead of doing what he was expecting.

The issue (example code included) was in how the data providers are expecting the data to be returned. His test was expecting an array but the data provider was returning things incorrectly. As Chris points out, the provider should return an array of arrays. The fix is easy, but could be confusing to someone not used to this slightly unusual return format.

Some methods have many parameters. Sometimes they start out like that, sometimes they grow like that over time. Even though a maximum of two parameters is preferable, configuration for a method that does a big thing is difficult. Take curl for example; curl has a lot of options and so several wrappers around curl have arisen to deal with configuring it in a more humane manner. How can we keep the clutter of many parameters as low as possible, while maintaining autocompletion?

He gives an example of a function that takes too many arguments and how it's difficult to read (and remember the right order/types to give). He does mention one way that's sometimes used - arrays - but you lose typing checks with that. His best recommendation is to use a fluent interface instead. Not only does it make it more readable but it also works with the autocompletion in most IDEs.

On the SitePoint PHP blog a new tutorial introduces you to collection classes in PHP, replacing the more basic array with something with a bit more power.

Applications frequently have objects that contain a group of other objects, and this is a great place to make use of collections. [...] A Collection class is an OOP replacement for the traditional array data structure. Much like an array, a collection contains member elements, although these tend to be objects rather than simpler types such as strings and integers.

He mentions some of the common problems with arrays (and the data they contain) and points out that the structure a "Collection" class wraps around it can help keep things sane. He includes an example of a basic collection class that adds/gets/deletes items from an internal (private) array. He fleshes out this class with code inside those methods and a few others: keys, length and keyExists.