In a new post to his site Matthias Noback makes an interesting suggestion about working with objects in PHP: that they should all be made in one, and only one, place.

Consider the following rule: "When you create an object, it should be complete, consistent and valid in one go."

It is derived from the more general principle that it should not be possible for an object to exist in an inconsistent state. I think this is a very important rule, one that will gradually lead everyone from the swamps of those dreaded "anemic" domain models. However, the question still remains: what does all of this mean?

He shares an example of an object (GeoLocation) that can be created with only the latitude value but points out that this leaves it in an invalid state. He updates this example to show a more complete implementation, one that prevents an object with partial setup from happening. He then talks about the aggregation of child entities and a "paper" metaphor. This metaphor - imagining a "paper purchase order" - helps him wrap his head around the structure of the objects and how they interact.

Sergey Zhuk has a new tutorial posted on his site showing you how to use child processes in ReactPHP to send emails asynchronously using Swiftmailer.

In PHP the most of libraries and native functions are blocking and thus they block an event-loop. For example, each time we make a database query with PDO, or check a file with file_exists() our asynchronous application is being blocked and waits. Things often become challenging when we want to integrate some synchronous code in an asynchronous application. This problem can be solved in two ways: rewrite a blocking code using a new non-blocking one or fork this blocking code and let it execute in a child process, while the main program continues running asynchronously.

This first approach is not always available, asynchronous PHP ecosystem is still small and not all use-cases have asynchronous implementations. So, in this article, we will cover the second approach.

He starts by creating the main HTTP server handler running locally on port 8080. He adds in an exception handler to catch potential issues and provides example code of an exception being thrown. With that structure in place he starts on the Swiftmailer integration, adding it to the exception handler and pushing the details of the exception into the message body. This is then modified to use the react/child-process package to wrap a new PHP file inside of a child process loop. The tutorial ends with an example of how to pass data between the parent and child process. In this case it's the message from the exception.

Continuing on from his first part of the series Cees-Jan Kiewiet has posted part two of his series covering the extension of ReactPHP's child processes.

react/child-process is very flexible and can work a lot of ways but sometimes you don't want to be bothered with the details of how it works and just want a simpler API to do that.

He mentions his wyrihaximus/react-child-process-pool package that makes working with the pool of processes easier and covers some of the "under the covers" handling behind it. He then shows an example of it in use, creating a pool that executes database queries via Doctrine's DBAL functionality to select the number of users from the users table. He then refactors it a bit using the wyrihaximus/react-child-process-closure functionality to make the child processing of a closure simpler.

In a new post to his site Cees-Jan Kiewiet walks you through the process to extend the ReactPHP project's child process handling (the first part of a series of posts).

react/child-process is very flexible and can work a lot of ways but sometimes you don't want to be bothered with the details of how it works and just want a simpler API to do that.

He then covers two packages where he used this "simpler is better" mentality and wrapped the current ReactPHP handling in a simpler API: one for defining "promises" on the child process and the other handles the messaging between the child and parent processes. He includes code examples for each of these, showing them in use to create simple operations.

Davey Shafik has a post today that talks about an exceptional change to PHP 7.0 and some updates that have been made to provide more of a hierarchy (a different one) that can make them easier to work with.

With PHP 7 errors and exceptions are undergoing major changes. For the first time, the PHP engine will start to emit exceptions instead of standard PHP errors for (previously) fatal, and catchable fatal errors. This means that we can now handle them much more gracefully with try... catch. But with this change, comes a whole new exception hierarchy.

He provides a tree of the error/exception relationships, what they inherit from and who their "children" are. He also talks more in detail about the "error" type exceptions: Error, AssertionError, ParseError and TypeError. He gets into more detail about catchable fatal errors and the userland handling of the Throwable type and extension.

On the SitePoint PHP blog there's a post from editor Bruno Skvorc showing you how to create recursive partials in Blade, the templating library that the Laravel framework uses internally for rendering output.

n this tutorial, we’ll go through the process of implementing recursive partials in Laravel’s Blade templating engine by means of the @each command. This will allow us to render data structures with an arbitrary number of nested children without needing to know the maximum depth of the array.

In his example, he's rendering the data from a nested set, a folder structure that could potentially go many levels down. He gives an example of the data he's working with in PHP arrays and how it could be outputted in plain old PHP. Of course, things have to be done a little differently in Blade and he includes the templates to do it - the main level and a partial that's used to output the folder information. He shows the use of "@each" in these examples and explains how it works and an example of the output.

Matthew Setter has a new post to his Master Zend Framework site today showing you how to use child and segment routes to create a routing table in your Zend Framework v2 application. These routes are "sub-routes" underneath a main route defined in the main router configuration.

Routing is one of the key requirements in modern applications, especially in Zend Framework 2; but they shouldn’t be overly-complicated. Today, we’re going to look at how to build a routing table, simply and easily using child and segment routes. [...] But how would we do that? Gladly, it’s quite simply, using a combination of [the] two route types: Segment and Child Routes. I’ve made a complete example, which’s available in this Gist. Feel free to skip straight to that. But otherwise, let’s step through the annotated version together.

He sets the stage with an example in a "writing pipeline" application that helps him predict his income from his freelance writing. He describes the main controllers and the routing configurations they might share. In his example code, he shows how to define the routes and modify them to use segments and child routes to handle constraints. There's also a section about extracting out the segments from the route.

In this new post to his blog Rob Allen shows you how to access the view variables from another ViewModel.

Unlike Zend Framework 1, the view layer in Zend Framework 2 separates the variables assigned to each view model. This means that when you are in the layout view script, you don't automatically have access to variables that were assigned the the action's view model and vice versa.

He includes snippets of code with an example controller and a sample view that fetches a value from a child ViewModel instance. He also shows how to access layout and configuration values in the view.

On the Re-Cycled Air blog Jack Slingerland has posted another in his "Dark Arts" series looking at some of the lesser used PHP features. This time he focuses in on daemonizing a process by forking it off into the background.

One of the many things you don’t often do with PHP (actually, I’m not sure you do this much with any language) is daemonize a process. A daemon is program that runs in the background (read more here). On Unix systems, processes are usually created by forking the init process and then manipulating the process to your liking. To create a daemon though, you need to get the init process to adopt your process. To do that, as soon as you fork the parent process, you kill the parent. Since you child process is parent-less, the init process generally adopts it. Once that happens, your process has been daemonized.

He uses the pcntl_fork function to spawn off the child process, detach it from a terminal window, create a ".pid" file so the system knows about it and then, of course, have the child script do something.

Padraic Brady has posted part three of his look at asynchronous processing in PHP applications today. The previous two parts introduced you to the topic and got you ready to work with child processes in a Zend Framework application. This latest part gets into the code showing how to fork the processes and handle communication between them.

With the theory heavy portion of the series out of the way, we can begin to explore the various implementation possibilities. In this part, we will examine implementing Asynchronous Processing using a child process, i.e. a separate PHP process we create from our application during a request. We'll analyse this implementation option before introducing the source code so we may understand its advantages and disadvantages.

He looks at both the advantages and disadvantages of processing with child processes and suggests a method to get a handle on the processes rather than just spawning new processes - forking. Some basic code examples are included, using the popen function to open the new child process and a Zend Framework example.