"Rowan Collins" wrote in message
news:calkijkr3os6ta55rjlq61o1+on-s3j8xfzmhjvqfxozlzwt...@mail.gmail.com...
On 18 January 2015 at 12:23, Tony Marston <tonymars...@hotmail.com> wrote:
"Rowan Collins" wrote in message news:54baba93.9070...@gmail.com...
On 17/01/2015 18:33, Todd Ruth wrote:
<<snip >>
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.
That's a good example of supporting old features adding complexity.
And adding new features does not also increase complexity?
You're right, it could solve this problem, at the expense of extra code,
with
extra possibility of bugs.
Adding new features also comes with the expense of extra code, extra
complexity, and extra possibility of bugs. I actually look at the notes for
each new release and I regularly see fixes to recently added features.
<snip>>
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.
Saying that something is complex in no way justifies making it more
complex; arguably, quite the opposite: compilers (and runtime engines) are
complex enough at the best of times, so features which add to that
complexity should be carefully evaluated
New features add to the complexity more than old features.
to avoid the whole thing becoming an unmaintainable mess.
Surely the core developers are competent enough to understand the necessity
for structured code? If they followed all the "best practices" that exist on
the web then how can they possibly produce code which can be described as a
mess?
<snip>>
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.
I'm not sure why you've replied with a well-worn argument about "no good
reason" to an e-mail whose sole purpose was pointing out a good reason. You
may think my reason is not valid, but that doesn't make this paragraph
remotely relevant or insightful.
The only "good reason" given is that developers should no longer be using
them. BC breaks should only be allowed for bug fixes or security issues and
never to enforce a new style over an older style. There are no problems with
PHP 4 style constructors which could not be solved with an extension to
https://wiki.php.net/rfc/default_ctor. The removal of PHP constructors
would, however, cause problems in all those applications which use them, and
this in turn would slow down the adoption of the new release. All you would
be doing is solving a very minor "problem" for yourselves but creating a
huge problem for your customers, all those 240 million websites which run
PHP applications. Such a total disregard for customer satisfaction would not
be tolerated in any other industry, or in many other segments of the
software industry, so dismissing this argument as irrelevant shows that you
haven't a clue about customer relations.
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".
Again, you have opted to ignore my point rather than respond to it.
You mean that it is perfectly OK to remove a feature which is no longer
supported? But the point is that PHP constructors *ARE* still supported in
PHP 5. All my classes, and I have hundreds of them, use PHP 4 constructors.
I am running version 5.6.4 and all my scripts run as expected and do not
throw out any E_DEPRECATED or E_STRICT errors.
I am not saying there is definitely sufficient justification to remove this
particular feature, but the idea that PHP could simply continue forever to
support every feature it has ever had, with no cost to anyone,
Adding new features increases code complexity and the possibility of new
bugs.
Bug fixes themselves can also introduce new bugs.
Leaving in existing features do not cause bugs.
and that
therefore anyone wanting to remove things is some kind of selfish dictator
is patently false.
If the only reason for removing an existing feature is "*I* don't use this
feature, and *I* don't want anybody else to use this feature" then I would
call that behaviour selfish and dictatorial.
Those proposing changes should certainly justify the benefits, but those
opposing should not simply pretend that those benefits cannot exist.
But the only benefits with the removal of old features is a smaller code
base for the core developers. The only "benefit" which is experienced in
userland is that applications which have run for over a decade suddenly stop
working.
--
Tony Marston
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
