The PHP 7 Revolution: Return Types and Removed Artifacts

[cpradio]

@tony_marston404

Tell that to the site owners whose applications suddenly stop working. They don’t know why it stopped working and they don’t even know about any script they need to run.

Then don’t upgrade? You shouldn’t upgrade your production box without checking how well your code runs on it to begin with. Doing so is always dangerous, regardless of how “stable” you feel the language is.

@tony_marston404

That’s the whole point. PHP 4 constructors have NEVER been marked as deprecated, and the removal of features which have not been marked as deprecated for some while - thus giving developers plenty of time to deal with it - should be considered an absolute no-no.

So are you saying if the PHP devs mark them as deprecated in 5.6.X you’ll be okay with it? As I doubt that. Plus I have a feeling deprecating a constructor syntax is much more difficult than deprecating an actual function/method. I’m sure it can be done, but it isn’t as easy as marking a function with [deprecated].

@tony_marston404

Not when you are dealing with enterprise languages which are maintained by competent professionals. The two major languages I used before switching to PHP both went through major upgrades which added new functionality but without ANY breaks in BC. If those guys could do it then why can’t the PHP cowboys do the same?

Which languages? As again, look at all of the other web related languages, .NET, Java, Python, Perl, etc. (either in past or present versions) All have introduced breaking changes at major versions.