>> 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
