"Levi Morrison" wrote in message
news:CAFMT4NrH+=6B4=kvyrmw1oc0n-_onndjawk0xzcxdvnv_pn...@mail.gmail.com...
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.
An error is only generated if I use BOTH types of constructor in the same
class. If I use the PHP 4 constructor on its own then no error is generated.
<<snip>>
To me this clearly indicates three things:
1. Having both forms of constructors is bad form (hence the E_STRICT)
I agree.
2. When both are present the new-style __construct is used over the
old-style PHP 4 constructor, meaning the language prefers
__constructor.
I agree.
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.
The fact that namespaces completely ignore a non-deprecated feature of the
language is a fault in the namespace implementation.
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.
My point is that if all constructors are PHP 4 style only then no error is
generated at all. It is therefore wrong to say that PHP 4 constructors have
been deprecated. The manual certainly does NOT say that they are deprecated.
That leaves us realistically with four options:
1. Bring full support for PHP 4 constructors
Good idea. Perhaps the RFC on default constructors should be extended to
cover both styles of constructor, in which case a call to
parent::__construct() will never fail regardless of whether a constructor
actually exists or not, or whether it is and old or new style constructor.
An existing feature should not be removed from the language unless it causes
a problem as its removal will not solve any problem and therefore cannot be
justified. If there is a problem then here are two choices:
(a) Fix the problem.
(b) Remove the feature.
Option (a) may involve a bit more work for the core developers, but option
(b) will always cause massive amounts of pain in userland and will slow down
the adoption rate for that release.
Any core developer who chooses option (b) is admitting two things:
(a) They don't know how to fix the problem.
(b) They don't care how much pain they cause for their customers all those
developers who create applications which run on over 240 million websites.
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.
Then why was a different method introduced in PHP 5 in the first place?
There was nothing wrong with PHP 4 constructors as they follow other
languages such as Java, C++ and C#, so they could never be described as
either wrong or inconsistent.
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.
Forcing your personal preferences on the rest of the PHP community will do
nothing but diminish your stature as a core developer in the eyes of those
members of the community who have different preferences. This is the
attitude of a small-minded dictator.
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
