Tony Marston wrote on 19/01/2015 10:37:
"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...
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?
Where did I say anything to the contrary?
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.
Yes, complexity is a necessary evil. That doesn't mean we should give up
trying to control the 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.
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.
Maybe. Also, old features add to the complexity *of* new features,
because every interaction between features has to be considered.
None of which changes my point, which was simply that supporting old
features adds some complexity, and removing that complexity can be a
good thing in itself.
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?
Sure, and some of those "best practices" involve refactoring your code
to have fewer edge cases where possible. Unfortunately, people may be
relying on those edge cases, so a compromise has to be reached.
<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.
No, that is not the only reason given. This entire sub-thread is me
giving another reason. It may not be a good enough reason, but it is a
completely separate reason.
Rather than simply assuming that people have no reason for something,
why not ask what their reasons are *and listen to the answer*.
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.
You've said all this before. I understand. I agree that it should be
taken into account. I don't think it's the whole story.
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.
That's not what I said at all. I said that adding a notice now might be
sensible because in future we can simplify the engine by removing the
support.
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.
Sure, just leaving code untouched can't introduce new bugs, although it
might harbour old ones that haven't been spotted yet. However,
maintaining emulation of an old feature while changing the code, or
introducing new features which interact with the old, can cause new 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.
My entire point is that it is not the only reason.
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.
Ah, so you admit there may be benefits? Again, I do not say that those
benefits are definitely enough to justify the change in this case, but
they are real, and I would like you to stop dismissing them.
Regards,
--
Rowan Collins
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
