The PHP 7 Revolution: Return Types and Removed Artifacts

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.

Scott

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 http://php.net/manual/en/language.oop5.decon.php 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 http://blog.ircmaxell.com/2014/12/being-responsible-developer.html 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 https://wiki.php.net/rfc/default_ctor 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.

3 Likes

Ammended, Tony’s name has apparently been updated. I am still not happy about the attacking nature of this article, or how rude the OP is, but cannot find a complaints button, which is very telling of sitepoint; I only signed to comment because I thought the article was so bad, so untechnically focused and so rude.

I Do share the idea, why would we tell the PHP core devs what to do, but Tony has made some great points, I do agree with in principle, and after the latest post (see below) it seems the article author agrees in principle too…

As the writer does say, it’s done now, and if for no reason other than this, I hope PHP7 crashes, and burns just like Python 2 did. It talks in places about compatibility with HHVM, as if that were some goal of PHP. In reality PHP should not be a web-application, it should form a part of it, and let more mature, more performant back-end compiled langs do the heavy lifting. After all, I never saw LUA trying to implement PDF utilities, or zip utilities, it simply hooks other frameworks like a lot of high-level utility langs do…

While I personally do not have the same view on the changes that is happening in PHP 7.0, I completely agree on that any functionality that is removed should be deprecated first.

At the same time, I do not believe this is what ruin the confidence in the language, what does that is the inter-tangled mess of internal function names, the order of parameters across the internal functions, poor support for multibyte charsets (not all of the internal functions support it) and missing vital data types like Decimal.

We are working with Enterprise solutions as well, and we cannot wait until the new version is released due to massive improvements to the internals, both for the speed increases and making it easier to make extensions. This alone should be enough for anyone to update their code base if they are using any of the functionality that is removed.

I have been called many things, but never a “Pillock” :wink:

No, no! Just not the recruiters! :smile:

My apologies, I have no idea how that got past me. I know many males with the name “Toni”, so it never seemed out of the ordinary. I have updated the post.

I agree, this should have been addressed by either not removing the functionality, or by marking it as deprecated first. Jumping to removals is not healthy for the language’s ecosystem.

But they, the makers of the language, believe they have a good reason. Who is to argue which reason is good and which isn’t? The majority? In this particular instance, I objectively believe you are the minority.

One thing I think would be a very important step forward is Scalar Objects to allow $str->replace(), $int->abs(), $array->combine() etc. Is there any discussion about implementing this? There’s an extension here: https://github.com/nikic/scalar_objects but it’s a bit limited at the moment.

This syntax change could also help fix a lot of the odd naming inconsistencies strpos vs str_replace, etc.

I currently know of no such implementation talks. Would be nice.