The PHP 7 Revolution: Return Types and Removed Artifacts

What about the sizable minority who learned from tutorials which still showed the old style constructors, the same constructors which have been fully supported, without being deprecated, for the last 10 years?

That’s because you cannot do anything but develop write-once-and-then-throw-away applications. When you have developed a large application, something which has hundreds of database tables and thousands of units, and have been supporting it for more than five years, then you will be able to feel the pain that is caused by frivolous BC breaks.

If you say so. :smile: I don’t think you can come close to identifying what applications I have in my portfolio that are actively supported and have been for over a decade.

They have been through upgrades from .NET 1.1 to 2.0, to 4.0 dealing with breaking changes in the process. It really isn’t as painful as you make it out to be. We’ve even converted a lot of the database structure to LINQ to SQL in the process or the Entity Framework.

So I’m sorry you are all of a sudden affected by a breaking change, but get over it already. It was bound to happen sooner or later.

And how many of those BC breaks caused pain to their customers, the application developers? Breaking the language for the convenience of the language developers should be weighed against the inconvenience caused to the application developers. If there is too much inconvenience then the convenience should be shelved.

And the inconvenience here is incredibly minor. If you’re upgrading the server then running wget php.net/fixscript.php && php fixscript.php is not exactly arduous.

Errmm, That’s why they call it “work” :wink:

I’ve been writing code for a few decades and in more than one language. What do I expect of any given language?

If it’s Beta, I expect breakage happening at some point, likely sooner rather than later.
Once out of Beta, I expect there to be minor releases for bug and security patching.
Given a DEPRECATED notice with a fair amount of time for me to adjust code is appreciated, but not expected.
Changing to a major release, I do not get surprised if things break, A major release is by definition not guaranteed to be backwards compatible.

If I want to change to a major release, I expect that I will likely need to adjust my code.
If I don’t want to adjust my code, I don’t change to the new major release version.

Easy.

2 Likes

Much like the issue you are experiencing the changes weren’t that difficult to upgrade to. Sure I may have spent a month on our largest application (including QA), but it wasn’t difficult.

Yeah, we should definitely not change the language because there are bad tutorials on the Internet.

3 Likes

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.

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.

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?

and almost everyone in the position where that might happen will be on shared hosting using an off-the-shelf solution such as wordpress. As far as I know none of the common CMS software (wordpress, drupal, joomla, etc) use PHP4 constructors.

Once again, the number of people affected by this change is going to be minuscule.

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.

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].

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.

2 Likes

out of interest is there any discussion about removing the PHP4 class field var keyword? It would seem if PHP4 constructors are then the var keyword should be too

I am not talking about web related languages. I am talking about the languages I used while working for a software house before the interweb thingy had been invented.

You mentioned that you worked in COBOL. I know quite a few COBOL programmers around my age (25-35) and all of them work in the 1978 COBOL Standard instead of the 2002 OOP Standard, because the 2002 Standard breaks everything.

They also all hate their jobs.

I think you’re just making stuff up at this point.

1 Like

No. According to the OOP Changelog at http://php.net/manual/en/language.oop5.changelog.php this change was sneaked in very early on, but removed in version 5.1.3

The last COBOL upgrade I saw was in 1985, and that did not break anything. I was not around for the 2002 upgrade as I had switched to another language by then.

You missed the point. :slight_smile: All languages eventually incorporate breaking changes.

1 Like

Well, then, if we aren’t going to compare apples to apples, let’s compare PHP’s decision to Assembly (or punch cards) then! sigh

I specifically said “enterprise languages” and not “web languages”. Enterprise languages are used by organisations to build enterprise applications. I used several of these before the internet existed.