>> We are talking about something deprecated since 10 years, about the 1st
>> major release in a decade, something we will use for the next 12-14 years.
>
>
> That is the point - PHP 4 constructors have NOT been marked as deprecated in
> the manual, and they produce no warnings at runtime.
>
> If they have not been marked as deprecated then you cannot suddenly remove
> them.
Warning: a long response with code snippets/
See this code (http://3v4l.org/ViPpb):
class Test {
function test() {
echo __METHOD__, PHP_EOL;
}
function __construct() {
echo __METHOD__, PHP_EOL;
}
}
new Test();
Note that there is an E_STRICT generated for having both constructor
types in all versions of PHP 5 and that __construct is actually used
as the constructor.
Now if you change the order of the definitions around (http://3v4l.org/BhPMm):
class Test {
function __construct() {
echo __METHOD__, PHP_EOL;
}
function test() {
echo __METHOD__, PHP_EOL;
}
}
new Test();
Note that __construct is still used and the E_STRICT is only
generated in PHP 5.0-5.3 (roughly; it's a bit more nuanced).
If you put a namespace at the top of the first example(http://3v4l.org/hWFnC):
namespace NS;
class Test {
function test() {
echo __METHOD__, PHP_EOL;
}
function __construct() {
echo __METHOD__, PHP_EOL;
}
}
new Test();
Then there are no warnings of any kind (since PHP 5.3.2), and
__construct is used as the constructor. The method test is just a
normal method.
To me this clearly indicates three things:
1. Having both forms of constructors is bad form (hence the E_STRICT)
2. When both are present the new-style __construct is used over the
old-style PHP 4 constructor, meaning the language prefers
__constructor.
3. Old-style constructors don't exist in namespaces. Notably this
was a conscious choice as evidenced by behavior that existed in PHP
5.3.0 - 5.3.2 where the E_STRICT was emitted like non-namespaced code.
This is the behavior of shipped, stable versions of PHP. I think it's
a bit illogical to conclude that just because there aren't any
E_DEPRECATED warnings emitted in PHP 5 that old-style constructors are
fully supported.
That leaves us realistically with four options:
1. Bring full support for PHP 4 constructors
2. Emit E_DEPRECATED when PHP 4 constructors are used
3. Drop support for PHP 4 constructors so they are just normal
methods, just as they are in namespaces
4. Maintain current behavior.
As already mentioned I think as an end result we shouldn't have two
ways to define constructors. Given that PHP already prefers the
new-style constructors I've proposed that we work towards dropping the
old-style, it's just down to a matter of how.