On 17/01/2015 18:33, Todd Ruth wrote:
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.
I've been following these threads for about 10 years and beg that php
internals continues to "live and let live".
There have been many, many threads over the years from what I would call
(with obvious bias) "OO fundamentalists". They seem to be at war with
code that is "bad form".
In the global cost/benefit analysis I don't see that the
benefits of purifying OO outweigh the costs.
Not everything is a matter of code style - supporting legacy features comes at a cost in complexity, and sometimes even performance. Whenever new features are added - such as the ability to call parent::__construct when the parent doesn't declare a constructor explicitly - decisions have to be made on how they interact with old features - such as PHP4-style constructors. And simply by having an accumulation of old features, the codebase is larger, harder to understand, harder to change, and has more surface area for bugs.
Deprecating a feature or raising an E_STRICT doesn't, of course, reduce this complexity by itself - indeed, it slightly increases it - but it paves the way for a future version to decide that this feature is no longer supported, and can be removed in order to improve the rest of the engine.
So, you are quite right to highlight the costs of doing this, and they may well outweigh the benefits in this case. However, you are wrong to assume that the only benefit to be weighed is "purifying OO".
Regards,
--
Rowan Collins
[IMSoP]