"Rowan Collins" wrote in message news:54baba93.9070...@gmail.com...
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".
This is an argument that comes up a lot, and it has some merit, sometimes.
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),
This problem is partly solved in the RFC for Default Constructors (see
https://wiki.php.net/rfc/default_ctor). If this were extended to cope with
PHP 4 style constructors as well then all the problems would be solved. Then
there would be no need to remove PHP 4 constructors at all.
and more consistent (all reserved magic methods begin with __, so any
method not beginning with that is safe to use however you like).
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,
All compilers are complex beasts - that is the nature of compilers. If you
cannot handle that complexity you shouldn't be working on a compiler.
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.
Removing long-standing features for no good reason (and a change in style is
never a good reason) does nothing more than frustrate all those 240 million
website owners who find that their existing applications will no longer run.
This is the primary reason why there is a slow adoption rate for each new
release. If you stop breaking the language then the adoption rate will be
quicker.
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".
Yet the reasons I have seen for removing an existing feature are rarely to
fix a problem but to make the language "cleaner" or "more consistent". What
this means in reality is "PHP would be cleaner if it didn't contain all
those features that I don't like and I don't use, and I don't want anybody
else to use them either".
Regards,
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
