I don't think using __construct over named-method for constructors really has anything to do with "OOP fundamentalism"; it was a design change to make certain things simpler (like parent::__construct), and more consistent (all reserved magic methods begin with __, so any method not beginning with that is safe to use however you like).
To add on to what you said, there’s also a quite important benefit that __construct is a lot more obvious in what it does.
Looking at the following code:
class Foo {
public $foo,
$bar,
$qux;
public function foobar() {
// ...
}
public function bar() {
// ...
}
public function foo() {
// ...
}
public function baz() {
// ...
}
public function qux() {
// ...
}
}
It’s not easy to spot the constructor at a glance, and it’s very easy to miss.
Compare that to the following:
class Foo {
public $foo,
$bar,
$qux;
public function foobar() {
// ...
}
public function bar() {
// ...
}
public function __construct() {
// ...
}
public function baz() {
// ...
}
public function qux() {
// ...
}
}
Far more obvious.
This actually tripped me up on more than one occasion when updating tests broken by the removal of PHP 4 constructors in php-src.
Perhaps this issue can be solved by the RFC on Default Constructors? See Sure, the constructor should probably be the first method, but *even if it is* it’s still nowhere near as obvious in PHP 4 style.
Similarly, what does the following do?
$this->foo();
It looks like a normal method call, and it is in a sense. But if you’re in Bar and inheriting from Foo, that’s a call to the parent class’s constructor!
Perhaps there should be a new rule which says that invoking a constructor with anything other than "new" or "parent::__contruct()" should be illegal, in which case this situation would generate an error.