The PHP 7 Revolution: Return Types and Removed Artifacts

Originally published at:

With the planned date for PHP 7’s release rapidly approaching, the internals group is hard at work trying to fix our beloved language as much as possible by both removing artifacts and adding some long desired features. There are many RFCs we could study and discuss, but in this post, I’d like to focus on three that grabbed my attention.

PHP 5.7 vs PHP 7

As I mentioned in the last newsletter, 5.7 has been downvoted in favor of moving directly to PHP 7. This means there will be no new version between 5.6 and 7 – even if the new version was only to serve as a warning light to those still stuck on outdated code. Originally, 5.7 was not supposed to have new features, but was supposed to throw out notices and warnings of deprecation about code that’s about to change in v7.

It would also warn about some keywords that are to be reserved in PHP 7, so that people can bring their code up to speed with a sort of “automatic” compatibility checker in the form of an entire PHP version. The thing is, however, as I argue in the newsletter, that most people technologically competent enough to follow PHP in its upgrade path by keeping up with the most recent version aren’t generally the type of people to actually be using code that might break in PHP 7.

While this is a good discussion to have, what’s done is done and the voting is over. What do you think about this?

Continue reading this article on SitePoint

I think we in “PHP Land” can be really happy Facebook came up with HHVM. It seems to me the PHP devs have gotten a wake up call and a more positive outlook for PHP can be seen for everyone. It isn’t perfect, but what is perfect in life? As for the exact changes in PHP7, I’ll wait until the first betas roll out to start to have an opinion on them.

As for Uncle Tony’s rant. Check out his request for support on LinkedIn’s PHP Group. He basically got stomped on by everyone who answered, including me. One of posters noted the best argument about removing PHP4 style constructors. He said…

Q: Again, two choices: both have identical results except one has a slight chance of failure and the other does not. Which do you choose?

A: Depends:

  • Uncle Tony: The option with the slight chance of failure.
  • Everyone else in the entire universe who has lived, is living, or will live: The option with no chance of failure.

The discussion is entertaining, if nothing else. :smile:


Sounds like Python 3…

Indeed! Missed that, thanks! :smile:

That is a common concern, yes, but we have the advantage in:

  1. that the changes won’t be that great and will remove only obsolete functionality which has no room in a modern language any more, allowing all modern packages, libraries, CMSes and frameworks to function as usual
  2. the community is much greater and far more involved with the lower level stuff in PHP (many are at least dissecting frameworks, if not building their own) so the manpower to convert those few packages that people actually use but which still won’t be able to digest PHP7 is more than present.

The only problem might be extensions, but even that will be largely taken care of by both the community and those extension developers whose extensions are still being actively used (most of them still keep an eye on them and keep them up to date).

I don’t think we have anything to worry about. With good repositories such as adopting PHP7 from day 0 and pushing out good resources about adoption and using the new version properly, I don’t think we’ll have much to fear. It’s just a matter of reaching those who are still in the dark, and that’s something everyone is already trying to do.

1 Like

One change I’d like to see in PHP 7 is the old mysql_* extension removed, imo people and companies have had more then enough time to have migrated away from it to either the mysqli_* extension or PDO. If they’ve not finished then they should really be 80-90% migrated

The vote just came through today. It is getting removed.


I believe they’ve just voted to unbundle the mysql extension from PHP in version 7. Although that doesn’t stop hosting companies from choosing to manually install it, which I’m sure some will.

I think a lot of people (those people, who have an interest in saving money on servers) will be eager to take up PHP7, because of the large performance boost and RAM savings it will supposedly have. I also really hope, a form of JIT compiler will also come not all too long after PHP7’s release.


1 Like

And of course now that the mysql_ functions are no longer defined in the core, the door is wide open for people to write their own mysql_ functions to wrap the mysqli_ ones just so they don’t have handle rewriting their code to use mysqli_.
I’m not saying I endorse it (I don’t), and I’m not saying it’s pretty (it isn’t), but you bet it will happen, simply because it’s (probably) the fastest solution to work around the removal of the mysql_ functions.

My first thought was “Oh they’re pulling a Java. It’s 5.7, but ‘PHP 7’ sounds better”.

I support the removing of the mysql_ extension, but i’m not sure I see the doom of it that Scallio points out - after all, what is PDO if not a wrapper around mysqli_ functions, if you only use it on mysql databases?

I don’t get it. Why on earth don’t the very smart dev people around PHP simply write “official” upgrade wrappers for each release, let alone for something like 5.6 to 7.0?

As a real world example I’ve used MySQLConverterTool from Github on 2 medium sized projects and didn’t have to tweak the end results, it “just worked”, and I couldn’t help thinking “my goodness, why don’t smart people write more of these converters?” so the rest of us have a better chance of staying uptodate with our projects.

I do not like PHP 7’s return type hinting syntax, Id rather have the function keyword replaced by the return type, like what you do in C++, Java and C#. The function keyword bothers me, especially used in conjunction with return type. Its a lot of typing, plainly ugly, and very inconvenient to use. Just compare these two:

public function getIterator(): Iterator //bad, ugly, but was chosen as the syntax...
public Iterator getIterator(); //good, elegant, but was not chosen as syntax...

It seems that the PHP internals are unwilling to make the function keyword disappear, not even optional at this stage. I hope return type hinting will be optional then, I aint likely to use this feature unless the syntax changes dramatically.

Just like PHP’s namespace syntax, I am fine with most of it, but cannot withstand the leading backslash(like \Exception, \PDO, etc…). For this reason I always import all namespaces, and never use the fully qualified names without importing, except when dynamically loading/instantiating objects of variable classes. sigh

It’ll be optional. There have been many discussions about the type before or after the function name, and this was chosen in respect to C++ and general habits PHP devs have built over time. Perhaps in the future, but I’m not at all bothered by this in the age of live templates. I just type “pfa ” in PhpStorm and get

public function functionName(): array {


The namespace syntax has been debated to no end, and this was the best solution at the time. What would you like to have instead? What bothers you about the backslash that much?

Well it can be after the function name, this is lesser of an issue to me. I just do not want to see the function keyword used in conjunction with return type hinting. To me its one way or another, either function keyword without return type, or return type without function keyword. If both exist in a method declaration, it looks extremely ugly and painful to the eye. Also a lot more typing and inconvenient to use.

For the namespace, I think you misunderstood me here. The backslash is not something I’d prefer, but its not really a big issue. What annoys me tremendously is the leading backslash, or more precisely, PHP’s namespace resolution rules. For instance, I am okay with Symfony\Bundle\FrameworkBundle\FrameworkBundle(), but \Symfony\Bundle\FrameworkBundle\FrameworkBundle() disturbs me. Do you see exactly what I mean now? The leading backslash is ugly and error-prone, I already lose track of how many times I’ve seen myself and colleagues getting syntax errors due to missing this leading backslash for Exception, ArrayObject and PDO classes. Seriously, have you seen another programming language that uses this ridiculous namespace resolution? We do not see things like .java.collection.arraylist, or .System.Data.Entity, right? So why do you have to use a leading backslash in PHP when referring to a class outside of the current namespace? Isnt this a language design flaw?

I agree with that, I’d rather all namespaces were resolved from root by default, rather than trying to be relative when the leading backslash is missing.

Yeah, I have no idea why PHP’s namespace does not resolve from the root by default, rather at the current namespace. The leading backslash annoys me so much, I always import all classes I so I do not have to use it. sigh I hope in PHP 7 this will be fixed, but well it may lead to backward incompatibility.

There is no chance of that happening - it would cause too many BC breaks on something that wasn’t even deprecated to begin with.

As you have seen fit to criticise my article then you must surely allow me to reply. BTW, the name is Tony with a “y”, not Toni with an “i”. “Toni” is a girl’s name, and while there are many who think that I am a big girl’s blouse (or even worse) spelling my name right would be much appreciated.

Note that although my article concentrates on the RFC for the removal of PHP 4 style constructors it also mentions another RFC on scalar type hints. It is the principle of the core developers breaking the language for no good reason that I (and a huge number of others) object to. Removing existing functionality in order to fix a bug or a security issue is a good reason, but removing something simply because you don’t like it is NOT a good enough reason.

“Please do not break our language”, pleads Toni, who seems intent on using its broken features.

How are PHP constructors “broken”? What are the problems they cause? They have been in the language for 15 years and coexisted with PHP 5 constructors for over 10, and I have been using them with every PHP release up to and including 5.6.4 without an issue.

Please also note that PHP 4 style constructors have NEVER been marked as deprecated in the manual (check for yourself) nor by the compiler, so they cannot be suddenly removed in the next release.

if you’ve kept such a codebase alive for so long, is there really a need to upgrade to PHP 7?

The need to keep abreast with the latest PHP release is highlighted in article All those 240 million website owners out their would LOVE to keep their versions of PHP up-to-date so that they can benefit from all the bug fixes, but they can’t upgrade if it breaks their applications.

It was the volume of BC breaks which caused the slow adoption of PHP 5, and if PHP 7 continues down the path of even more unnecessary BC breaks then it’s adoption rate is liable to be even worse.

If PHP 7 cannot be used to run existing applications which run happily under PHP 5 then it does not deserve to have “PHP” in its name as it will effectively be a different language and not the same language with improvements.

The sentence “This means that code which I wrote 10 years ago should still run today, and should still run 10 years from now.” is, to me, madness – you definitely and absolutely should not expect this of ANY language across major versions.

I disagree. I have been designing and building enterprise applications for over 35 years using languages such as COBOL (16 years) and UNIFACE (10 years). In all that time both languages went through major upgrades without any BC breaks whatsoever. While new features were added the language developers took great pains to maintain all the existing features. This is because the developers who maintained the language were competent professionals who put the needs of their user community before their own personal preferences.

There are some people who say that PHP will never be anything more than a “toy” language as it will never be good enough in which to develop enterprise applications. I know for a fact that the language IS good enough as I do nothing but develop enterprise applications, but the only stumbling block is this continuous flow of unnecessary BC breaks.

Enterprise applications deal with enterprise data and not only does enterprise data have a long shelf life it is expected that the applications themselves should have a long shelf life. Developers of enterprise applications therefore expect two things from their language - stability and longevity. If PHP cannot provide these then PHP will never become an enterprise language.

I have been told by many critics that I should grow up and do what the core developers tell me to. Instead my message to the core developers is quite simple - if you want PHP to be treated as more than a language for writing toy websites then it is YOU who need to grow up. If you want PHP to be a “big boy” language then it is about time you adopted “big boy” practices and started to treat your user base with compassion instead of contempt. You can start by NOT breaking the language without VERY good reasons.

1 Like

Thank you for the response, I’m glad to have you chiming in here!

The problems have been named in the internals list, and have been, in part, mentioned in your article. Some breakage here and there and unexpected behavior. Nothing critical from my point of view, but it happens nonetheless.

I completely agree with you on this one. Functionality that is to be removed, especially if considered to have a large enough user base still, should first be marked as deprecated. But who is to judge how large of a user base is still using a given functionality?

And what is the status of these languages today? How used are they? How many courses do you see on them? How many newbie developers ask “Should COBOL be my first language?” rather than inquiring about PHP?

On a final note - I’d like to inquire: does fixing your codebase to respect the new constructor rules really entail so much effort? Surely if you search for all instances of such behavior and have a sufficient amount of unit tests in place you could fix all of it in a day or two? I really am curious as to the nature of your application that is so brittle such a change would destroy it, and yet still incompatible with minor code alterations as to avoid this disaster.

1 Like

The problems have been named in the internals list, and have been, in part, mentioned in your article.

The so-called problem with traits and namespaces is that they completely ignored PHP 4 constructors in the first place, which is the fault of the developers who implemented those changes.

The problem of “accidentally” creating a method with the same name as the class and thereby “accidentally” creating an unwanted constructor is purely the developers fault. Those of us who have been around long enough to know what we’re doing would not make such a newbie mistake. This is a developer error, not a language error.

The problem with a subclass not knowing the name of the parent constructor, of if even one exists, will be solved by if it were extended to deal with both styles of currently valid constructor.

I completely agree with you on this one. Functionality that is to be removed, especially if considered to have a large enough user base still, should first be marked as deprecated. But who is to judge how large of a user base is still using a given functionality?

There are over 240 million websites out there running PHP. Unless you are prepared to run an audit on every one you cannot say for certain that any piece of functionality is not being used. It has already been stated that significant portions of the PEAR library still use PHP 4 constructors, and there must still be a significant number of applications out there which were developed using PHP 4. If the PHP 4 constructors have never been marked as deprecated then their developers had absolutely no idea, no warning that their code needed changing.

There is a rule that nothing can be removed from the language without it being marked as deprecated first, and PHP 4 constructors have never been marked as deprecated. As the next major release as 5.6 will be 7 (the need for 5.7 was voted down) it will therefore not be possible to remove them in 7.

And what is the status of these languages today?

You don’t understand the difference between deliberately moving to a new language and updating the existing language. My company moved from COBOL to UNIFACE because the market for new COBOL applications for the HP3000 dried up. UNIFACE provided the ability to develop applications which could run on a variety of platforms with shorter development times. The original version was for the desktop only but a later version also provided the ability to access applications via a web interface. Despite the numerous upgrades to the language there were never any BC breaks whatever ran in the current version would always run in the new version.

I decided that web applications were the way of the future, and that UNIFACES’s ability to develop web applications was too clunky for my taste. As the language could never be modified to meet my expectations I decided to switch to a language that was designed specifically for the web, not one with a web add-on. That is when I discovered PHP, and after proving to myself that it could do what I wanted I stuck with it, and I am still with it after 14 years.

Updates to a language, such as new features and bug fixes, are perfectly OK, but BC breaks are not. It is one thing to move to a new language because the old one doesn’t do what you want, but it is another thing entirely to change the language into something else and completely destroy the old language. Any new version of PHP which is incapable of running EVERY existing application that runs under the latest version of PHP 5 does not deserve to use the name “PHP” as it will effectively be a new language instead of the old language with new features.

On a final note - I’d like to inquire: does fixing your codebase to respect the new constructor rules really entail so much effort?

It’s not the effort, it is the principle. The idea that the core developers can remove long-standing functionality from the language FOR NO GOOD REASON and thereby break existing applications is wrong. It destroys confidence in the language. The core developers should learn to be more considerate to the millions of developers who use the language and less selfish in trying to force their personal preferences on the entire community.