In this new post to his site Matt Stauffer looks at the "higher order messaging" in Laravel's collections as a part of his series covering features in Laravel 5.4.

It seems like it was just last year that collection pipelines took over the Laravel world. Taylor had introduced collections to Laravel a while back but they sat somewhat under-appreciated until Adam Wathan wrote his book Refactoring to Collections about how they can transform the way you write a lot of your PHP code.

In Laravel 5.4, collections got a few boosts. Let’s take a look at a few.

He starts by talking about the higher order messaging design pattern and how it is different than just using something like foreach to iterate through a set. He then applies this to the Laravel collections, showing how they're implemented there via the "filter" and "pipe" methods.

Leonid Mamchenkov has a post to his site showing how he solved an interesting problem in one of his recent projects: determining the order to use items based on their dependencies.

One of the projects I am working on at work presented an interesting problem. I had a list of items with dependencies on one another and I needed to figure out the order in which to use those items, based on their dependencies.

He gives the example of database tables where it would be required to export the tables so that the relations between them are maintained when imported back in. He gives some example data, a basic nested PHP array, and defines the relationships between them (just strings in this case). While he did solve the problem, he wasn't happy with the solution. Instead he went looking for other options and found graph theory to be a good match. He briefly cover what the theory involves and links to an example that basically does what he needs...but is written in Python. He finishes off the post sharing his refactoring of this logic into PHP including a recursive "dependency resolver" and the output showing the correct ordering for loading objects based on their dependencies.

Marc Morera has posted an interesting article to his site suggesting a re-thinking of how event listeners are used in applications and libraries.

Let’s talk about Event Listeners. Do you know what an Event Listener is? Well, if you are used to working with Symfony, then you should know what is intended for. If you don’t, don’t hesitate to take a look at the Symfony documentation. This post aims to start a small discussion about how an Event Listener should look like if we really want to keep things decoupled.

The starts with a brief summary of the post (tl;dr) for those in a hurry but goes on to explain things in a bit more detail too. He starts by laying a foundation, introducing what event listeners are. He also shows how they're commonly implemented and used (in Symfony2 specifically but it applies more generally too) to trigger actions in applications. He suggests decoupling things a bit more from the flow of the action and allowing, in this case, access to both the order and the customer (on a "order created" action). He takes it one step further and decouples the sending of an email into a service and then creates an instance of this when needed in the event and not before.

The SitePoint PHP blog has a recent post where they dig into the details of the Chain of Responsibility design pattern, a commonly used structure that makes for easier workflow handling and encapsulation.

The Chain of Responsibility is a behavioral design pattern that processes a request through a series of processor (handlers/receivers) objects. The request is sent from one handler object to another and processed by one (pure implementation) or all of the handlers. All the handlers are part of the chain.

They get into the detail of the parts of the pattern first: the abstract handler that defines the structure and a set of concrete handler classes based on this structure. He also mentions a few other object types that could be involved including a Client, Request and Response objects. He includes an example of the base abstract handler class with "setSuccessor" and "handler" methods to provide the "chain" from one handler to another. He creates a more advanced version of the handler that does some additional checking on the handler results to see if it needs to continue. Finally, he gets down to the Client class that handles the ordering of the chain before processing. He also shows how a service container (dependency injection) could be integrated to manage creating object instances.

Mathias Noback has posted another in his series looking at the concepts and implementation of command bus handling in PHP. In this new post he looks at some of the responsibilities of the bus and provides a few examples to help drive the point home.

In the previous post we looked at commands and how you can use them to separate technical aspects of the input, from the actual behavior of your application. Commands are simple objects, handed over to the command bus, which performs the change that is needed. [...] So the command bus contains some kind of a lookup mechanism to match commands with their handlers. Some command bus libraries use a naming convention here (e.g. handler name = command name + "Handler"), some use a kind of service locator, etc.

He starts off talking about the main point of the article, giving an overview of what he sees are the basic responsibilities of the command bus. He also sheds some light on methods he's seen for keeping it from becoming a "big inarticulate unmaintainable class". He then gets into his two examples: database transaction handling and protecting the original order of commands. He shows how his SimpleBus package handles most of this for you and shows how it follows the "chain of responsibility" design pattern to make it work.

In his latest post Mathias Verraes looks at "higher level programming" in PHP. Higher order programming is a style of programming that uses components (like functions, modules or objects) as values.

Let’s have some fun with higher order programming in PHP. I’ll start by showing how to program with Lambdalicious (or λlicious for friends) and introduce the real meat along the way. Don’t worry too much about the dark magic that may appear to power some of the features of Lambdalicious. It’s on GitHub if you’re curious. Just follow along and keep track of all the functions.

He breaks his examples up into (lots of) different examples, each with example code:

• Atoms
• Lists
• Functions
• Conditionals
• Loops & List Processing
• Deduplication
• Filter and Reduce
• Functions returning functions
• Partial Function Application
• Composition
• Piping

He finishes off the post talking about Lambdalicious and how, in reality, it's just not suitable for anything useful as written in PHP. The language just doesn't have the right functionality to make it work sufficiently...even HHVM.

If you're the kind of person that wonders more about the internals of PHP and how it works "under the covers" you'll find this new post from Nikita Popov a good read. It talks about how PHP handles its order of operations in more complex evaluation statements.

At this point many people seem to think that the order in which an expression is evaluated is determined by operator precedence and associativity. But that's not true. Precedence and associativity only tell you how the expressions are grouped.[...] What does this tell us about the order of evaluation? Nothing. Operator precedence and associativity specify grouping, but they do not specify in which order the groups are executed.

He gives a few examples to illustrate his point including multiple increments of the same variable at one time and how it's the "fault" of the compiled variables that were introduced in PHP 5.1. He shows the opcode version of the same PHP userland code and talks briefly about how to avoid this odd functionality in your application.

Matthew Setter has posted the third part of his series looking at the Zend Framework 2's DbSqlSelect component and its use. In this latest (and last) tutorial, he talks more specifically about columns, limiting and ordering.

Welcome to the third and last part in this series, introducing you to working with the ZendDbSqlSelect classes in Zend Framework 2. In part one we looked at building SQL Where clauses using the where related functions, predicates and closures, as well as compound queries. In part 2, we looked at all forms of SQL joins as well as a slightly more esoteric feature of SQL – UNIONS. Here, in part 3, in the words of Coldplay, we’re going back to the start, and looking at the fundamentals.

He looks at three specific elements - the class constructor, the "limit" and "order" functions and the "Expression" class. He includes sample code showing how to create the class - one normally and one bound to a specific table. The next example shows how to define the columns to be selected using the "select" method. Finally, he shows the use of the "Expression" objects to perform SQL operations in the query (like "COUNT").

The team that has brought you the infamous PHP ElePHPants in the past is back with another round - the 6th generation of the cuddly PHP mascot in both traditional blue and pink.

April 19, 2011 PHPère is happy to show you the first pictures of two premature elePHPant the 6th generation of PHP. As you can see ... ElePHPant the blue, is in great shape and has found its new home very pleasant

These are shots of the first turnouts of this latest batch and the rest will follow in June/July of this year. Those that have already ordered them will be contacted soon and, if you're interested in picking up some of your own, send them an email for complete instructions.

If you've been trying to get your hands on one of the cuddly little mascots for PHP (the elePHPant) but haven't managed to yet, there's some good news! Another run of the fuzzy little animals is being done (the 6th) and this time they're offering something new - pink elePHPants.

As we are now out of every of the 5 first generation of the elephpants, it is time to start a 6th. You'll find here all information to include yourself. [...] Fill in your elephpants wishes. We do not need any payement now. We will contact you directly before starting the generation for the actual payement.

Their schedule hopes to end the pre-order process on December 20th (just three days away) and to strat production on these pre-orders by January 10th. The end results would be shipped out for delivery in April 2011. If you'd like to lay claim to some of your own, go over to the order form and select the size (large/small) and the color (blue/pink) and fill in the contact info. Unfortunately, because of production restrictions, single elePHPants cannot be ordered, so consider getting together with a local user group and all chipping in for a box!