the Numiton blog

PHP bad practice: the use of extract()

Working with complex data structures in PHP requires the use of associative arrays. Even PHP classes are an extension of this concept. There are always disadvantages when one does not have alternatives (e.g. strictly defined data structures - see "struct" in C), but at least there are lots of built-in functions that work with arrays. Operations such as sorting, searching, merging, iterating with foreach are thus supported out-of-the-box for associative arrays.

One operation is perhaps a little too dynamic in nature, with unexpected side-effects. It is the extract() function.

The problem

According to the documentation, the extract() function imports variables from an array into the current symbol table. In its simplest form, extract(array("a"=>3)) will assign the value 3 to the variable $a.

The problem here is that you need to know what keys the array holds, both when calling the function and maintaining it.

Let us consider this simple function declaration:

function display_user_details($user) {
  extract($user);

  echo 'User name: '.$user_name."\n";
  echo 'User age: '.$user_age."\n";
}

Calling this function with the argument array("user_name" => "Mike", "user_age" => 20) is a valid operation.

But whenever you call this function, you need to check which key refers to which piece of the user's data.

So even in its simplest form, the usage of extract() raises issues. Factor in that there are multiple ways of doing the extraction, based on combinations between the $extract_type and $prefix arguments:

EXTR_OVERWRITE - if there is a collision, overwrite the existing variable
EXTR_SKIP - if there is a collision, don't overwrite the existing variable
EXTR_PREFIX_SAME - if there is a collision, prefix the variable name with $prefix
EXTR_PREFIX_ALL - prefix all variable names with $prefix
EXTR_PREFIX_INVALID - only prefix invalid/numeric variable names with $prefix
EXTR_IF_EXISTS - only overwrite the variable if it already exists in the current symbol table, otherwise do nothing
EXTR_PREFIX_IF_EXISTS - only create prefixed variable names if the non-prefixed version of the same variable exists in the current symbol table
EXTR_REFS - extracts variables as references

All this suggests that there are several options to choose from but the code becomes harder to understand. The more entries the array has, the more the extract() call does and harder to trace the data becomes.

The solution

My suggestion is to keep it simple. There are at least three alternatives:

work directly with the array: $user["user_name"] doesn't look that bad after all
explicitly "import" the variables: $user_name = $user["user_name"]
use function arguments with default values: function display_user_details($user_name, $user_age = 18)

Depending on your specific needs, there might be other alternatives. But any of the above three will make your code easier to maintain and extend.

New whitepaper added

We're often asked about the quality of the translated code, from an architectural point of view.
So we have coded a small test application in PHP, translated it into Java using plain servlets and then Spring MVC, and we discuss the results in a new whitepaper: Exploring nTile PtoJ output flavors.

This is the abstract of the whitepaper:

"The nTile PtoJ migrator is built in a modular fashion, allowing easy adjustments of the output. These adjustments can be as broad as the application architecture itself, or as narrow as varying a threshold for the package import (“import package.*”) statements.

The paper explores two major output architectures (called flavors from now on), plain servlets and Spring MVC. A comparative analysis highlights the differences as well as the common points between these two."

And this is the summary:

Introduction

Common considerations

The test application

Translation to servlets

Translation to Spring

Conclusions

PHP bad practice: variable reuse

Anyone who has worked with PHP knows that it is extremely permissive with variables and their types. There's no need to declare variables, not even at class level, and data types cannot really be enforced. This is one of the greatest strengths of weakly typed dynamic languages, but it can be easily used the wrong way.

The problem

Variable reuse is one such unfortunate case, which can easily lead to unmaintainable code.

Let me illustrate by this example:

$fruit = array(1 => “orange”, 2 => “banana”);
// Some code using the $item array
$fruit = $fruit[2];

As you can see, the $fruit variable starts out as an associative array and is used as such to perform various tasks. After a while, it gets reassigned and points to a string typed value inside the array.

Now what if you need some other items from your fruit array in some newly added code? You will not be able to do that, since the array is no longer available. This is especially troublesome if the functionality is added by someone else. That developer will need to figure out what is going on, modify the existing code and only afterward implement the new feature.

During our various migration projects, I have regularly encountered code that uses this annoying pattern. Such constructs are not yet explicitly handled by our type inference algorithm and so we end up with Java variables of java.lang.Object type. This is obviously not a nice thing in the generated code.

Not even larger PHP code base is free from variable reuse. From the open-source world, phpBB and WordPress come to my mind as heavy users of this construct.

The solution

Variables should be named consistently, based on the data they hold. While regarding variable types and their declarations the opinions are diverging (see static vs. dynamic typing), the meaning of the variable content is fundamental and should be reflected by its naming.

With this in mind, the above code should rather look like this:

$fruits = array(1 => “orange”, 2 => “banana”);
// Some code using the $item array
$favourite_fruit = $fruits[2];

Now isn't this much cleaner and maintainable? Had I written this, it would make me sleep better at night :-)