In this new post from Lars Strojny, there's a discussion of an "antipattern" - using the constructor for more than it was intended, the "verbose constructor".

Constructors are often used to shortcut dependency injection and parameter passing on instantiation. This is a valid practice and often leads to shorter code. [...] Instead of creating a new instance of "Money" and calling three setter, everything can be done compactly in the constructor. [...] So for the money object this works pretty well. The code is easy to read, but wait, the first argument can be grasped easily, the second too, but the third? It is not too obvious that it is a divisor is passed.

He compares three different ways to get the data into the class - the already-mentioned parameters in the constructor, passing an array into the constructor and using full getters/setters to push the data into the right places (with fluent interfaces even!).

On the PHP::Impact blog Federico Cargnelutti has posted a comparison of using static factory methods to create an instance of a class versus making an object, calling the constructor.

Normally, creating an instance of a class is done by calling new, which calls the constructor. Static factory provides a static method that returns an instance of the class. So, you are using static factory instead of the constructor. Providing a static factory method instead of a public constructor has both advantages and disadvantages.

He includes some of the advantages of the factory method and others for the normal call to create an object. He also mentions some comments made by Dagfinn Reiersol in a blog post about public constructors.

According to the PHP in Action blog, public constructors can be hazardous to your (application's) health and should be replaced.

Everybody who writes object-oriented code knows about constructors. You need them so the program knows how to instantiate objects, right? And you especially need them when a lot of things have to be done while instantiating an object. [...] So why would I be skeptical of public constructors?

The solution, as he sees it, is to make a "constructor" that's actually called statically with parameters that returns an instance of the class it's in as well as performing the action. He argues that this can help make the code much more readable for some types of method calls.

In a new blog post today, Hasin Hayder points out an interesting bug he found in the Reflection functionality that's offered in one of the latest PHP5 series release, version 5.2.1 (also found in 5.2.2). It deals with an issue in the ReflectionParameter object.

[Despite the closing of this bug] there is still the following bug alive in ReflectionParameter object, I tested it against the PHP version 5.2.1 . So what is this bug? The reflection parameter cannot retrieve the default value of a parameter if the next parameter has no default value. PHP simply omits all the variables before that variable and return only values after that variable.

He illustrates with a test class that uses reflection to get the parameters for the constructor. Unfortunately, the object only comes back with the last attribute. This is solved later in the comments, however, when it's discovered that the parameters, some of which are optional, are not in the "correct order" - optional parameters should always follow the required.

Tobias Schlitt has provided a helpful hint for developers working with lots of objects, methods, and singleton patterned functionality to keep out of the same trouble he faced.

During my current exam phase I'm working on some tiny private project to relax after learning. In there I'm using a main controller class, which implements a singleton pattern and initializes several sub-controllers while being created. The singletons purpose is, that the other controllers can access to main controller and its functionality whenever they need, without storing a reference each.

The problem with the code (he gives snippets) was a recursive loop that was suddenly appearing. He finally tracked it down to a constructor in another class that was accessing the main controller's constructor. The issue was that the constructor was never finishing up, so a valid instance wasn't returned, so the whole thing started all over again.

In this new post on his blog today, Nick Lo provides an entertaining look at getters, setters, and constructors in the context of - what else - a children's book (in the style of the "Mr. Men" series).

One day, while refactoring a web application from procedural to object oriented code, Mr Dizzy decided to use constructors in a way that anyone in Cleverland would have pointed out was really not very clever.

The cutesy story relates Mr Dizzy's quest for an easy solution to using setters and getters. Unfortunately, he makes the wrong decision and puts them in the constructors, causing all sorts of trouble all around. Definitely a great way to relate a message (kids books do it all the time, right?) - kudos to Nick for the idea.