Alejandro Celaya has a recent post to his site showing you how you can delay constructor execution in your services by making use of the "lazy services" functionality provided by the Zend ServiceManager component.

A couple years ago I wrote a post about how to improve PHP applications performance by using zend-servicemanager lazy services.

In that article I explained how the ServiceManager takes advantage of the proxy design pattern to delay the creation of services, when they are marked as lazy.

That can improve performance if the object is resource consuming, but that is not the only advantage behind proxies.

He starts with a use case for using these "lazy services" based on some changes in an open source library he maintains to add in geolocation support. The library requires a database file when the object is created but on the first run, no file is downloaded yet. He made use of the lazy service loading to only initialize the GeoIp2 library when it is requested and not when the script starts.

Matt Sparks has posted a tutorial to his site introducing one of the more powerful but often misunderstood parts of the PHP language: its Reflection functionality.

Beginning work on the Analyze PHP framework, specifically the container, brought reflection to my awareness. Before that I had maybe heard the term, but I definitely hadn’t used it intentionally. Although it sounds like a scary computer science concept, it’s not. It’s actually quite simple:

Reflection is the ability of a computer program to examine, introspect, and modify its own structure… That’s it.

He starts the tutorial by introducing some of the basics concepts behind reflection in PHP and what it has to offer. He then shares some code examples of it in action getting class properties and getting the constructor. He also shows the use of other built-in PHP functions getting the class methods and the class name.

On the Stitcher.io blog they've shared a post that makes some suggestions about where a curly brace belongs and how that might differ from situation to situation.

Dedicating a whole blogpost to curly brackets might seem like overkill but I believe it's worth thinking about them. Not just because of one curly bracket, but because there's a bigger message in all this. Thinking about how we read and write code not only improves the quality of that code, it also increases our own and others ease of mind when working with it. It can improve the fluency of your work and free your mind to think about real important stuff.

[...] I wrote about visual code improvements a while back in a previous blogpost about cognitive load. Today I want to focus on that one little, yet very important character in our codebase: the curly bracket. More specifically, we're only going to look at the opening curly bracket, because there's little to no discussion about the closing one.

The post goes on to show several different example situations and where they think the "most correct" placement for the curly brace is. They alos talk about the difference between their use on constructors versus control structures. The main recommendation, however, is to keep things consistent across the codebase.

The PHPBuilder.com site has posted a tutorial talking about dependency injection in PHP applications covering not only the use of dependency injection (DI) containers but also constructor, setter, property and reflection based injection methods.

Dependency injection is a software design pattern that implements the inversion of a control concept for resolving dependencies. According to this concept, a class should not configure its dependencies statically, but should be configured from the outside.

A dependency is an object that can be used (a service) and an injection is the passing of a dependency to a dependent object (a client) that would use it. Passing the service to the client, rather than allowing a client to build or find the service, is the fundamental requirement of the pattern.

The tutorial starts out with a simple example of a set of classes that depend on each other through the creation of internal objects. They then show how the different types of dependency injection can help reduce these dependencies with brief descriptions and sample code for each. The final example, a dependency injection container, gives a quick example but also links to several package options you could pull into your application including Pimple, Aura.Di and PHP-DI.

Christian Weiske has posted a quick guide for those still dealing with PHP 4-style constructors in their code and how to upgrade them for PHP 7 (as it's completely deprecated now).

PHP 7 deprecates PHP4-style constructors. In PHP4, class constructor methods had the same name as the class. This was bad when switching base classes; you did not only have to change the class' extends declaration, but also calls to the parent constructor. PHP5 then introduced the generic __construct method name for class constructors, which solved the problem. ?

PHP7 will output a deprecation message when a class with a PHP4-style constructor is loaded

He suggests that a "quick fix" is to just rename the method to __construct and let PHP handle things as expected. However, dependencies in other classes (calling them in a PHP 4 way) could break because of this. He suggests a "real fix" that can be put in place until the remainder of the code is migrated - a method named the same as the old constructor but just calling __construct internally.

Ken Guest has a quick post on his site with a helpful hint for those updating older codebases. You can use PHPUnit & PHP_CodeSniffer to locate old constructors in the PHP4 format (constructors named after the classes).

There are less than seven days left until PHP 7 is released, which drops support for old-style constructors – the ones where a method is a constructor if it shares the same name as the class. You don’t want to spend too much time scrolling through codebases for that though do you? Better things to do, like watch videos of conference talks you’ve missed and such. Well, you’re in luck. If you use php_codesniffer (and if you don’t, well shame on you), you’ll be able to get a report of old-style constructors fairly quickly.

He includes examples of the commands you'll need to use to sniff out these older constructors, making use of the built-in "Squiz" coding standard and the "Generic.NamingConventions.ConstructorName" sniff but only on PHP files. He also shows how to alias it to a bash command and export the results to a CSV file.

Shameer C has a post to his site showing you how to automatically inject values in constructors on Slim 3 based applications. This makes use of the inheritance of constructor parameter functionality the Aura.DI container makes available.

In the previous blog post we have discussed how to replace the default Pimple Container with Aura.DI in Slim framework 3. Aura.DI gives us more flexibility in terms of managing dependencies. We saw one most useful feature in Aura.DI, Inheritance of constructor parameters, that will help us to avoid repeating common parameters for Controllers and Models. In this article we will see another advantage of the same feature.

He gives an example of how, with the default DI container in Slim (Pimple) you have to make a new instance of a class manually each time you need it. He talks about how Slim 3 internally resolves controller classes (using a CallableResolver) and a small change that can be made to prevent you from needed to define every constructor into the DI container and allow for more dynamic handling.

On the SitePoint PHP blog today Bruno Skvorc has written about the PHP 7 revolution and some of the changes coming with this next major version of the language (including return types and the removal of some functionality).

With the planned date for PHP 7’s release rapidly approaching, the internals group is hard at work trying to fix our beloved language as much as possible by both removing artifacts and adding some long desired features. There are many RFCs we could study and discuss, but in this post, I’d like to focus on three that grabbed my attention.

He touches on a few topics in the post including:

• the debate that came up about PHP 5.7 versus PHP 7
• The addition of return types from functions/methods
• The removal of PHP4 style constructors
• Changes to the extension API

Obviously, since PHP7 is no where near release status, all or some of these things could be subject to change. For example, the removal of PHP4 constructors is still being hotly contested on the php.internals mailing list at the time of this post.

Tony Marston has posted a plea to the core developers of the PHP language when it comes to some of the changes happening with constructors in classes: "please do not break our language."

This post is addressed to PHP's core developers who are proposing to break our beloved language yet again in the next major version of PHP (version 7) by removing functionality which has worked perfectly for years simply because it does not fit in with their ideas of how it should be done today. I am talking about PHP RFC: Remove PHP 4 Constructors (and this post on php.internals) which proposes that all code with PHP 4 style constructors be made invalid in favour of the "correct" method which was introduced in PHP 5. This is despite the fact that both types of constructor have lived quite happily side by side for over a decade and that large volumes of code, including PEAR libraries, were written in the PHP 4 style.

He suggests that this kind of change would require quite a bit of code to be changed, causing headaches for a large audience out there using older PHP code. He then gets into some of his opinions and thoughts about who "owns" PHP - is it the core development team working on the language itself, the community that uses the language (or a combination of both)? He proposes two definitions of "improvement" in respect to the needs of developers using the language and core developers. He suggests that the core developers are changing the language "just because they can" and that breaking backwards compatibility with something like this is a big mistake.

He then shares some of the comments from the php.internals mailing list on the subject of the constructor change, both for and against. He also points out a few other places where backwards compatibility was broken and the resulting changes that had to be made by developers. He suggests a "if it ain't broke, don't fix it" kind of approach

If there is a choice between a lazy or incompetent core developer doing only half a job and leaving the 240 million members of the greater PHP community to clear up his mess, then it should be obvious to anyone who has more than two brain cells to rub together that it is the core developer who needs to put in the extra effort so that the greater PHP community does not have to.

Mathias Verras has a new post to his site about an idea he calls "named constructors". This method uses static factory methods to simulate the idea of a constructor and initialize the object.

PHP allows only a single constructor per class. That’s rather annoying. We’ll probably never have proper constructor overloading in PHP, but we can at least enjoy some of the benefits. Let’s take a simple Time value object. Which is the best way of instantiating it? The only correct answer is “it depends”.

His example shows the typical constructor creation with variable arguments, but points out that this can get messy quickly. His other method, the factory methods as "constructors", can make for a cleaner interface and makes the class more flexible. They make the object able to be initialized with different types of values and even satisfies the Single Responsibility Principle. He goes through a few examples using his "Time" class, showing how different "constructor" methods can be used to handle inputs ranging from a normal hour/minute format out to a "from minutes since midnight" value.