Design Pattern Archives - Page 2 of 2

Today, Joshua Warren asked an interesting question on Twitter:

Feature flags in Magento (1|2). Any open source modules for it yet? At least a common approach? @allanmacgregor @jcowie @fbrnc #realmagento

— Joshua Warren (@JoshuaSWarren) 14. November 2015

I had thought about the topic earlier and if some genereric feature flag module would be worth developing. My conclusion was that it was too trivial in the end and I would just build feature toggles as needed for the respective project.

Feature Toggles: What and Why?

Feature toggles are a way to roll out partially developed features and keep them disabled in production, so it is often mentioned in the context of continuous delivery. They support the “ship early and often” paradigm and decouple code deployment from feature activation.

But feature toggles (or “feature flags”) also can be used to roll out new features gradually, for example only for a certain customer group, based on user location, or for randomly selected users, as with A/B testing.
Continue reading “Use Feature Toggles in Magento”

Anonymous function calls are a well-known pattern in JavaScript but there are also use cases in PHP where they make sense. Of course PHP 5.3 with its Lambda Functions is required!

But let me first introduce the pattern shortly:

In JavaScript you often have code that just has to be executed when loaded but you really don’t want to pollute the global namespace. The solution is to create an anonymous function and call it directly:

(function() {
  var some, local, variables;
  // do something
})();

Why should you want this in PHP?

Imagine an application that is not fully object oriented (yes this is the reality and yes, sometimes that even makes sense) and has some include files which execute code directly. Now if you don’t unset all local variables at the end you leave a big mess in the global namespace. See the analogy?

Unfortunately the following is not posible with PHP Lambda Functions:

(function() {
  $localvar = 'foo';
  // do something
})(); // Parse error: syntax error, unexpected '('

But there is still good old call_user_func(). Since Lambda Functions are objects of the Closure class which again is of the callable “type”, it fits perfectly our needs:

call_user_func(function() {
  $localvar = 'foo';
  // do something
});

Now what if there are variables from the outer scope that you need or want to change? Of course you could use the global keyword but that only works if you are refering to the global scope and there is a better way: The use keyword.

Look at this example:

// test.php
function test() {
  $readMe = 'Hello';
  $writeMe = 'World';
  include 'include.php';
  echo 'index.php: ', $readMe, ' ', $writeMe, "\n";
}
test();

// include.php
call_user_func(function() use ($readMe, &$writeMe) {
  $temp = $readMe . ' ' . $writeMe;
  echo 'include.php: ', $temp, "\n";
  $readMe = 'Good Bye';
  $writeMe = 'Internet';
});

test.php results in the following output:
include.php: Hello World index.php: Hello Internet

Let’s go through it step-by-step:

The $readMe and $writeMe variables are present in the local scope of test(). Since we also include include.php there, the scope stays the same within this file.

Using the anonymous function call we then open a new scope but take over $readMe and $writeMe with the use statement. Any other local variable from test() will not be present!

It is important to know that variables passed with use work similar to function parameters, so a copy is used by default (call-by-value). You can change this behaviour to call-by-reference exactly like in function declarations with a “&” denoting a reference.

Now our function prints the contents of $readMe and $writeMe to the screen (“Hello World”) and assigns new values to both variables.

Afterwards, back in test() the $writeMe variable that was passed by reference will hold this new value whereas $readMe is still the same because it was passed by value. Therefore the output is “Hello Internet”.

Of course $temp will not be set, it was a local variable in the anonymous function scope and destroyed after its execution.

One step further

To keep code maintainable the inclusion of files should not have side effects on variables which is on one hand assured by the anonymous function call but on the other hand bypassed again with use parameters by reference. To keep this transparent I recommend doing the wrapping around the include statement instead of (or even additional to) inside the included file:

// test.php
// ...
  call_user_func(function() use (&$writeMe) {
    include 'include.php';
  });
// ...

Now regardless what include.php contains it is clear that it will only have effects on $writeMe

Conclusion

If you work with procedural code and include files (and let it be just configuration files) anonymous function calls are a good way to keep the code more maintainable. They constrain unwanted side effects and make wanted side effects more visible without further documentation. So the two extra lines should really be worth their effort!