Larry Garfield has a new post to his site sharing a method for short and safe array iteration based on a "neat trick" he picked up reading a mailing list.

PHP's largely loose, dynamic typing has plenty of both pros and cons. One con in particular is that you don't always know for sure if a value you're trying to use has been set yet, or is non-null. PHP will dutifully whine at you if you try to use a null value, sometimes fatally. (Yet another reason to structure your code to avoid nulls, period.)

One place this comes up in particular is in foreach() loops, especially when working with nested array structures. (PHP lacks a struct type, but makes anonymous hash maps so easy that they get used as the uber data type, for better or worse.)

He gives an example of looping through a dataset with a foreach where the array index reference is used to reference the source array. While you could always wrap the loop in an if statement to check first, he has another interesting method to do the same thing. With the help of the null-coalesce operator (??) in PHP 7, you can essentially say: "if the array index referenced is null/does not exist, use an empty set". Check out the rest of the post for code examples putting this method to use.

Sergey Zhuk has a new post to his site that hopes to help you better understand "ticks" in ReactPHP. Ticks are a feature of the tool that are used to track when a process or queue has been executed.

Tick is one loop iteration where every callback in the queues has been executed synchronously and in order. ReactPHP event loop implementation has two main methods to work with ticks: nextTick [and] futureTick.

Both methods can be used to schedule a callback to be invoked on a future iteration of the event loop. When being executed a callback receives an instance of the event loop as an argument. But then what’s the difference between next and future ticks? Let’s figure this out.

He then starts in talking about the difference between "future" and "next" ticks, illustrating with a simple "stream select" loop. He then shows how to work with the tick queue for both the future and next ticks and what the result is of each function call inside them. He includes the output of his sample scripts and what happens if a few things change.

Consider a tick as one loop iteration where every callback in the queues has been executed synchronously and in order. That means that a tick could be long, it could be short, but we want it to be as short as possible. So, don’t place long-running tasks in callbacks, because they will block the loop. When a tick a being stretched out, the event loop won’t be able to check the events, which means losing performance for your asynchronous code.

In this new tutorial from PHPBuilder.com, Jason Gilmore shows you some of the more advanced things you can do with arrays in PHP (specifically in the areas of iterating through them and manipulating their contents).

Sporting more than 70 native array-related functions, PHP's array manipulation capabilities have long been one of the language's most attractive features. [...] There are however many array-related tasks which ask a bit more of the developer than merely knowing what part of the manual one needs to consult. Many such tasks require a somewhat more in-depth understanding of the native features, or are possible only when a bit of imagination is applied to the problem.

In his examples he shows how to do things like sorting a multi-dimensional array, iterating recursively (with the help of a RecursiveArrayIterator), converting an object to an array and doing "natural" sorting on an array's contents.

In a recent post to his blog Eric Reis talks about "why PHP won" in his web application development over other (web scripting) languages:

Some of them are probably still cursing my name, because - let's face it - PHP can be pretty painful. As a language, it's inelegant. Its object-orientation support is "much improved" - which is another way of saying it's been horrendous for a long time. Writing unit tests or mock objects in PHP is an exercise in constant frustration. And yet I keep returning to PHP as a development platform, as have most of my fellow startup CTOs. This post is about why.

He includes four things (that would be needed to counter the information cascade that PHP has) a "new challenger" language might need to burst PHP's bubble.

• Speed of iteration (a good write/test/debug cycle)
• Better mapping of outputs to inputs
• A similar standard library
• A better OOP implementation

He gets a bit confusing in there, moving back and forth between "PHP is good" and "PHP is bad" comments but he does come back to the one thing that everyone can agree on - regardless of your personal bias, you should always consider this: "it's all about picking the right tool for the job".