Forgive me, but can I throw a can of petrol on to the fire here?
First (as pointed out above) hard coding dependencies is going to turn out badly the first time you want to change that dependency.
The first use case is usually testing. If you test a class and it's dependences at the same time, the number of lines of code under test grows an order of magnitude. This slows your productivity down by roughly half the same factor (assuming you spend roughly half your time writing tests and the other half getting them to pass).
Except for small apps, this is just the kind of thing you don't want to do in the constructor.
You do want stuff to happen in the constructor besides this. Between the __construct() call and the init() call your object is in an indeterminate state. Any call on it will generate a bug. You want a bug factory?
The C++ crowd (who have a far more demanding job having to manage memory as well) have a phrase "construction is initialisation". In other words, if you have any set-up to do, do it in the constructor.
A useful point here is that if you go...
$working_at_last = new GoodLuckGettingThisUpAndRunning();
...and the constructor throws an exception, you never get an object in the variable $working_at_last. This is handy if the cause of the exception would leave the object useless and unrecoverable. If you your init() code contains such a possibility, move it to the constructor. Then your program is guaranteed never to see an object in that state. Stronger than strong typing - how cool is that?
The exception to all of this is lazy construction. If you are doing this I won't disturb you further. You need all the concentration you can get.