Changes in PHP 7
All functions which returned true in PHP 6 now return false, and vice-versa.
PHP 7.0 was launched today, so we've asked @sydphp organiser and #phunconf convener Jack Skinner to explain its significance. Over to you, Jack ... PHP is the language we love to hate and often hate to love. After celebrating it’s 20th birthday earlier this year, it's clearly here to stay, not least because version 7 arrived …
I know people complain about PHP but I've come to quite like it. We're currently migrating away from a Java app to a more AJAX like PHP based app and I've got to say progress is faster than we expected.
I'll take a look at PHP 7 but I don't think we'll use it until next summer.
Understandably some things no longer apply as they have been fixed or removed but much of the blog is still valid today. One of the reasons PHP is so popular is you can simply copy and paste tons of code from the web. This also explains why many PHP sites are vulnerable as those users that just use the example verbatim from the web don't realize that they are examples and not meant to be production based code.
I know people complain about PHP but I've come to quite like it.
Sure. What's not to like?
I mean, assuming you don't want predictability or correctness. This alone is sufficient evidence that PHP is inherently, mind-bogglingly broken, in my opinion. (The PHP bug link on that page is also worth reviewing, particularly the comments from core PHP developers that, yes, the broken behavior is correct, and everyone should shut up and go home.)
Mind you, I use PHP in the web development class I occasionally teach, and I've used it for production websites (for academic conferences and the like). But it's a shambling fucking horror nonetheless. It rivals MUMPS and the Praat scripting language at approaching pure evil without being an "esoteric" language (i.e. deliberately difficult, like INTERCAL or Unlambda or Brainfuck).
"With so much changed, PHP 7 is almost certainly not backwards compatible with your existing code, especially if you’re running anything remotely legacy (yes, even you there with the ‘updated PHP 4 project)."
And this is why I hate PHP from a sysadmin / hosting perspective. Because when the time comes when you will need to upgrade then good luck explaining to your customers that their hacked together website has stopped working and that it's most definitely not your fault but that of the PHP team. Then get ready for: "So why can't you keep using this version?" and in the end you'll end up with some customers probably leaving, others muttering about bad service and some who see what this is and will then start antagonizing the others for not keeping up.
Fortunately this is a major upgrade (5 to 6) which is a lot different and easier to explain than the 5.2 - 5.4 (iirc) update which also broke a lot of stuff.
I know I'm quite the critic here but meh; I think the non-backwards compatibility only shows evidence of a sloppy design. Quite frankly this is also exactly why I'm so in favor of the "Unix mindset": let everything perform small tasks and then bring those tasks together to do bigger things. Sure: from a management perspective not always the easiest but it is most certainly the most flexible.
On the positive side though all these changes may also create more work for the administrators and programmers. I suppose that could also be a positive thing, especially in these times. But quite frankly.. I'd rather stick to using stuff which keeps working while also keeping its history in mind.
I agree, but the history of PHP is terrible. Breaking backwards compat for a better language is fine by me.
Now if only they'd fix crap like:
bool in_array ( mixed $needle , array $haystack [, bool $strict = FALSE ] )
mixed strpos ( string $haystack , mixed $needle [, int $offset = 0 ] )
Not that I care about up or down votes, but I am curious why somebody has downvoted my comment about inconsistent argument ordering in PHP.
If you read this, could you tell me why? I honestly want to know. Do you like being kept on your toes by its inconsistency?
I can't think of any reason why anybody would disagree with that.
I'm gonna say this as a professional PHP developer who's arguing for creating more tedius work for himself: PHP tries way too hard not to break BC and fix idiocies.
Of all the things you can say about PHP it's problem certainly isn't that it breaks things going forwards. Serious well-respected internals devs have left the project trying to get minor BC breaks inserted for big gains and running into the brick wall otherwise knows as the internals team.
The only place they allow BC breaks is over actual bugs that were never intended (there are admittedly exceptions but the thing they changed was usually stupid like the $this debacle) and even then it only comes after massive multi-month slanging matches.
The thing that still annoys me- and which gives away its hacked-together origins- is the broken precedence of the ternary ?: operator. This means that the likes of this...
$something = COND_1 ? result_1 :
COND_2 ? result_2 :
COND_3; /* I'd normally use additional tab and indentation spacing for readability */
...which works in every other C-derived language I've used, doesn't work correctly in PHP (causes confusing bugs if you forget about it). (#) Under PHP, you'd have to slap on additional nested pairs of parentheses for each additional condition, which quickly becomes unworkable and makes it more hassle than it's worth regardless.
But to be honest, it's more the principle that such an obvious and fundamental aspect of the language is stuck in that broken state because of an early oversight that just screams "naff" to me. :-)
(#) Some people dislike that type of structure and say you should be using switch statements or multiple ifs anyway... I don't agree, but PHP comprehensively tips it in their favour.
@LosD - Hosting companies should not even be offering this, it encourages a viscious circle - Customers pay to have a script developed/installed for them and fail to keep it maintained, never being updated or patched.
How can this be a good thing? All if does is help maintain the cycle is security issues, obsolete scripts and outdated versions of PHP.
Hi, the post is not very accurate stating PHP7 is not backward compatible(BC). There is a 92% chance that your legacy code will work without much change. I upgraded my app directly from PHP5.3 to PHP7 and it just works.
Note about PHP7; Its major goal is to deliver improved performance with less code changes from developers (https://wiki.php.net/rfc/phpng#proposal).
A summary of codes that might break are;
1. Removed PHP4 style constructor (https://wiki.php.net/rfc/remove_php4_constructors)
2. Removed deprecated api such as ereg (now pcre), mysql (now mysqli) https://wiki.php.net/rfc/remove_deprecated_functionality_in_php7
Infact, for full details on BC changes please read more on http://php.net/manual/en/migration70.incompatible.php.
I have been hit by the PHP 7 upgrade. It may or may not good for programers but I use CuteNews and my older sites will not work under PHP 7. I am paying my hosting company to allow me to continue to use PHP 5.4. I have tried upgrading the CuteNews installations and stoped after having to mess around, spending hours feeding existing news posts through CKEditor as after the upgrade all the posts (over 300) were showing the HTML code. My Search Box failed as well persisting to stop with a message that the text entry in the box was too short. I went through the source code and found where the file search.php tested the entry and found that the entry was there was correct - for some reason the logic was not working. CutePHP has not been able to guide me through a way to update my installations. The issue is that I doubt whether anyone but an expert could get my sites working under PHP 7. The PHP gurus should have realised that making PHP 7 not upgradable would put some users out of business. I think that I will need to ask CutePHP how much they would ask to ungrade the two remaining sites for me.
Python 3 has been out for 7 years now and the majority if scripts will still only run on 2.7. Why? Because Python 3 has relatively minor differences in its syntax, methods and behaviour and many modules don't run on it.
To make things worse, some stuff from 3 has been backported to 2 which puts even less incentive on switching to the new version. And then some software such as Django wants to run on 2 *and* 3 so it has to use compatibility kludges like Six to paper over the differences.
The same will happen to PHP if it doesn't either a) support the old syntax even in some degraded mode or b) put a definite end of life on older versions. The end of life could still be a few years hence to give people time to update their code but it should be clear that end of life means end of life. No feature backports, no additional bug fixes etc. Activity will wind down on a schedule and all focus will be on the new version. The faster the transition, the better for everyone in the long term.
Next up to the plate with backwards compatibility breaking changes will be Perl 6. The fun and games with migrating code from Perl 5 will probably put Python in the shade by comparison.
The key difference here is Python 2.7 always was and still is a fairly credible language. V3 fixed/broke dodgy design decisions like overloading strings as byte arrays, but it wasn't a wholesale refactoring of the entire standard library and operator evaluation logic because those things were not catastrophically broken in the first place.
PHP7 starts from a different position. Those basics (and MUCH more) are catastrophically broken. Either PHP7 terminates backward compatibility on a heroic scale (and nukes it from orbit, just to be sure) or it is pointless.
A more accurate parallel is/was IE6. Ubiquitous, entrenched, critical to line of business functions but fundamentally broken to the core, just like PHP.
Any language that uses "whitespace" as a core feature is f**ked up by design from the start!!.
It's not a feature of the language, it's part of the syntax. A subtle but important difference because it emphasises readability as a desirable characteristic of source code. But, hey, who needs code review?
>>"it emphasises readability as a desirable characteristic of source code. But, hey, who needs code review?"
This is an argument that has been re-hashed many times, but what the Hell:
1. You don't need this to be part of the syntax to incorporate it into coding standards. All other languages are capable of having automatic coding standards checks without this.
2. Programmers are capable of indenting code without the language trying to force the issue or mandate how code should be readable. They don't need to be told it is "a desirable characteristic of source code"
3. It introduces weird scope for errors and restriction for no good reason.
Other than the whitespace issue, Python is a lovely language.
3. It introduces weird scope for errors and restriction for no good reason.
Particularly in 3 which now complains if you've mixed tabs and spaces for your indenting. It is bad practice and should be avoided, but it's not exactly the easiest thing to spot if you've got limited tools to hand at the time
Particularly in 3 which now complains if you've mixed tabs and spaces for your indenting. It is bad practice and should be avoided, but it's not exactly the easiest thing to spot if you've got limited tools to hand at the time.
Why? It removes ambiguity. Which text editors can't be configured to display control characters?
You don't need this to be part of the syntax to incorporate it into coding standards. All other languages are capable of having automatic coding standards checks without this.
It's Pythonic to make it both required and obvious. It means one less line in your own coding standard. This is straight from any good UX book.
Yes, the whitespace pisses off coders coming from other languages which use other block conventions. But they're just moaning about their cheese being moved. From all other perspectives it is literally a no-brainer.
Python hipsters??!! What??
Hipsters either use Haskell, Swift or JS depending on subspecies (UberGeek, FanBoi or WebMonkey). Python?? No chance...
I agree about whitespace though. Making the style guide into syntax is dumb as a box of rocks.
"The key difference here is Python 2.7 always was and still is a fairly credible language."
The point is that if you are developing a language you want to keep your developers as close to the tip as possible. Otherwise you end up wasting time and effort supporting multiple versions of the same language. Perhaps Python 2 is fairly credible but it has obvious sticking points that Python 3 set about to rectify (print(), integral types, unicode, syntax changes etc.). These aren't insurmountable differences - run 2to3 and it will identify and fix most of these and warn on the rest.
What's missing is the urgency to move. The urgency isn't there - indeed some of the urgency was removed by backporting stuff. If Python.org had put a definite end of life on the old version (e.g. 5 years) it would have focused minds and they wouldn't be in this situation now. 3.x would have stabilized faster as more people devoted their attention to it and 2.x would be deprecated and forgotten about.
Apart from the lack of support for u"" and b"" literals, there is remarkably little difference between 2 & 3 syntax and a compatibility shim is tiny.
The real problem is that Python 3 is only ideally better than Python 2. It brought no performance improvements.
Things are only now starting to change with async.io
PS. I want my print statement back. I've been writing Python 3 syntax for years and I still don't think that print should be a function. Even less with f"" literals in 3.5
@DrXym - "Python 3 has been out for 7 years now and the majority if scripts will still only run on 2.7. Why?"
Because 2.7 is still supported as a long term support release (until 2020), and loads of people have working software they have no desire to change. The success of Python has meant that a lot of users have large legacy code bases.
The biggest thing keeping 2.7 around had been that most Linux distros install it by default because they use it for their administration software. You could normally count on it being present without having to install a version of Python. For example, with my own Python software I used to say that I supported version 'x' of Ubuntu, Debian, etc., and then develop and test assuming the default version of Python.
However, most of the major distros are working on making 3.x their default version for the distro's own use (e.g. administration software), and will be making 2.7 an optional download only soon. That will give developers less incentive to keep providing backwards compatibility tor 2.x in future. Almost all the major third party libraries support 3.x, the exceptions mainly being ones which are no longer supported by their developers.
Anything new that I'm doing now requires 3.4 or newer as there is no point in creating something for 2.x now given how it is being phased out. A lot of other developers seem to be doing the same.
The main problems people have with moving from 2.x to 3.x seem to be unicode related. I suspect that PHP 7 users will find similar issues. With 3.x strings are now all unicode, rather than switching back and forth on the fly between unicode and ASCII like 2.x does. That has exposed a lot of latent unicode related bugs in existing application code, as well as problems where people were abusing strings to handle binary data (I'll admit to being guilty of the latter).
Opinion on the unicode switch seems to be split between the "why can't everyone just speak English" crowd who think foreign languages are a load of nonsense, and people who actually speak those languages who tend to be very strongly in favour of the change. Again, I suspect that PHP users will be going through the same process.
As for comments by people on white space and indenting, yes, neatly and consistently indented code in Python isn't just a good idea, it's mandatory. Developers whose self image derives from creative use of curly braces just have to get used to the notion that there's one official way of formatting code and Python enforces it mercilessly. The nice result of this is that the Python parser reads the code the same way that I do (by indentation), eliminating bugs cause by curly brace versus indent inconsistency.
I suspect that the transition from PHP5 to PHP7 will take years, largely due to hosting providers being slow to provide it and due to legacy code issues. As a result, PHP5 will probably be around for years to come. That however is the price of success. If everybody uses your code, that tends to create a great deal of inertia. It's why people are still running COBOL programs that were written before they were born.
"Because 2.7 is still supported as a long term support release (until 2020), and loads of people have working software they have no desire to change. The success of Python has meant that a lot of users have large legacy code bases."
But it's only long term because of the badly thought out idea of making it so in the first place. It should have had 5 years of bug fixes and then frozen - perhaps only defrosted for a critical security issue. Such a roadmap would have focused minds and it would have motivated everyone to move up - core developers, 3rd parties, dists etc. But at the moment its like the Python community has put each leg on a stool which are moving further apart for no good reason. I didn't even mention Jython, IronPython, PyPy etc. which could probably do without the grief of choosing where to focus their limited resources.
Besides, Python 3 isn't *that* different. There's a bit of a mess around Unicode and issues around print / integer calculations and some lesser stuff. Scripts can identify and in some cases fix the issues or offer advice. The timeline should have been faster.
As for Unicode, from experience the best solution for any language is that all source code is treated as UTF-8. Even if the source is laden with Japanese comments it's still more compact (and tool friendly) to store it as UTF-8. It still looks right in the text editor but it losslessly saves as UTF-8.
At runtime the choice is harder since Unicode requires 32-bits encapsulate every code point but that's horribly inefficient. Java (and QT and Windows API) uses UTF-16 which *mostly* works until you hit some esoteric ancient language and then its guaranteed to break. So personally I'd use UTF-8 at runtime with string classes that would encounter non-ASCII code points enough to be well tested and robust. The biggest danger of all encodings is that length_of_string != display_length and iterating / splitting strings can be dangerous and for that the only solution is to educate developers not to do dumb things.
It should have had 5 years of bug fixes and then frozen - perhaps only defrosted for a critical security issue
I strongly disagree with this.
When writing enterprise code, you need it to be supportable for 10-15 years. If the language is going to be obsoleted in 5, it's the wrong language to use.
He's talking about EOL'ing a version, not the entire language
But if you EOL a version without backwards compatabililty, it comes to the same thing; you need the current version to run code that was written 10 years ago. If you don't have that, your language is not useful for that task.
@DrXym - "It should have had 5 years of bug fixes and then frozen"
The LTS decision came about because of a lot of user demand, especially as it is an important part of most major Linux distros and companies like Red Hat have long term support requirements for it due to their own customer commitments. The core developers would rather have stopped support for 2.7 as soon as 3.1 came out. Having said that, there are no new features going into 2.7, just security fixes. All the major Linux distros however are in the process of switching to 3.x, or have switched already. Version 2.7 however isn't going to totally disappear until the last Red Hat customer still running it upgrades to a RHEL version that doesn't have it, some time in the 2020s.
@DrXym - "As for Unicode, from experience the best solution for any language is that all source code is treated as UTF-8."
Python has been around for quite a long time, longer than Java. Going to unicode was always going to be a problem, and the 3.x series is where they finally decided to bite the bullet and do it. The other changes came along for the ride, as they decided if they were going to make any breaking changes, they may as well do them all at once and get them over with. They weren't going to hack these changes onto the side, they made them thorough going and comprehensive to ensure they were done right and also done once and for all.
In 3.x, source is treated as UTF-8. With 2.x you could specify that at the beginning of the file, but it wasn't by default and most 2.x programs don't do it.
@DrXym - "At runtime the choice is harder since Unicode requires 32-bits encapsulate every code point but that's horribly inefficient.Java (and QT and Windows API) uses UTF-16 which *mostly* works until you hit some esoteric ancient language and then its guaranteed to break."
In the newer versions of 3.x, they encode UTF-8 string data using 8 bits, but switch to larger sizes if non-ASCII code points are encountered. This saves a lot of RAM in applications which process string data, such as web apps. Increased RAM consumption due to Unicode was in fact another factor keeping some people from switching to 3.x until that change was made.
The variable character length isn't a problem because that is all handled by Python behind the scenes. You don't get access to the raw memory buffers, you do it through Python's built in string methods and syntax. All strings are unicode, and binary data is now a different data type. There is no more mixing the two together.
I remember someone telling me that when PHP5 came out he decided to switch to Python because either way he had to learn a new language.
Rewriting your own code is often not the biggest problem for a version change: dependence upon third-party libraries can be a real deal-breaker.
I hate PHP with a passion but the new version does bring some significant performance and memory improvements. This might be attractive if you can switch with minimal changes.
OTOH just drink the Node.js kool-aid and go with the callback flow!
@Whitter - "Honest question: is PHP really the best option if one is prepared recode?"
I prefer Python, but if you've got a large existing code base in PHP you're probably going to find it's much easier and faster to port from PHP 5 to PHP 7 than to rewrite the whole application.
If you do a complete rewrite, I would strongly recommend writing complete tests as part of the development process. I be there are a lot of PHP 5 web developers who are going to wish they had when it comes time to port to PHP 7.
"Honest question: is PHP really the best option if one is prepared recode?"
I have a PHP site which I wrote about 5 years ago. It had all kinds of include statements to pull in headers, footers and navbars, substitute strings into the template etc. which it did via PHP. I even had some code that would read an XML file on the server and spew out links.
I'm in the process of rewriting it all. I reckon that I can use static html for of the site (via a preprocess node module at build time) and use angular for the rest. The only thing I'm leaving as PHP is some forum software which talks to a MySQL backend.
I also have a mouldy old Dojo app which I'll junk at the same time. I could port up to a later Dojo but it's probably easier to rewrite it to a more popular framework.
Oh yes from experience. PHP is just so damn productive (Performance, and Speed of development).
The Ultimate secret of writing awesome code with any language is, keeping it simple.
If you use like OOP paradigm, you can let spl_autoload solve your include file issues.
Again, from your comment, it seems you are not doing so much logic with the PHP code. I rather prefer you use no framework. Should you insist, just use a simple micro framework like slim, silex etc.
My reasons are, it is easy to make a project bloated with framework files and composer dependencies. Infact, your code can grow exponentially from 100kb to 30mb with frameworks, composer etc.
In all, PHP just works. If you have more concerns, please share it.
"It's useful for sorting arrays of objects, used in a callback function for usort and the like."
Bricks are also useful too it all depends on implementation. Used correctly it can build something functional and even aesthetically pleasing. Used improperly and you have a terrible coder screaming in agony as those inflicted with the bad code do something about it.
Used correctly it can build something functional and even aesthetically pleasing. Used improperly and you have a terrible coder screaming in agony as those inflicted with the bad code do something about it.
Pish, posh. This describes nearly every programming language that has ever existed. Except binary (probably).
@ Preston Munchensonton
"Pish, posh. This describes nearly every programming language that has ever existed. Except binary (probably)."
Sorry if I wasnt clear, that is what I was musing over. I have known people who get their knickers in a twist over goto statements! I was trying to say that both commenter's are right in how this can make code better and worse.
Because it's soooooo much clearer to have to read two different conditional expressions.
A big challenge when maintaining code is tracking conditions. Used properly, <=>, strcmp, sign() etc allow you to drive actions based on the differing results of a single condition. Same goes for a switch/case/select.
It also avoids having a bunch of analogous ordering functions for different types.
I also think it's an unlikely typo given key positions.
Cos perl6 will be out in a few weeks and it needs a bigger number (so hence be better) than that.
perl6 also has may extra special operators which can either be impossible to enter UTF-8 characters or made up from multiple other characters.
Obviously perl6 is not backwards compatible either, so we can expect the new year that the internet will melt down and it will be the end of times etc.
Historically, there was a PHP6 with an huge list of features. So big, that the developers basicaly gave up and started coding subsets of those features and release them as php 5.1, 5.2 etc.
So to not make confusion with the PHP6 plans of old, the new PHP is now 7.
Cos perl6 will be out in a few weeks and it needs a bigger number (so hence be better) than that.
Perl 6 will never be released, and also the PHP team clearly don't care about perl version numbers. The PHP 7 thing is semi-logical despite my loud public protestations about it (it was the wrong choice but.. people..).
Likely won't see a large uptake from other devs I know. It's another language, misnamed perl.
The switch to a java runtime means it loses and important part that made perl superior - the use of a co-optimized runtime and language. As the perl 5 books mention - there's a reason perl 5 (and down) don't use bytecodes. Speed, and the lack of ability to optimize frequent ops with custom C in the engine.
From the way I see it, this are just tools and should be seen as such.
I have really enjoyed easier success working on/starting web projects with PHP than Java (even JSP), C# personally. However, this does not mean I think it is a must use technology for all project -- Other language inclusive. For most web based project, PHP easily rocks (as long as you don't try to bend PHP into Java, python, ruby or some other language). Should you decide to choose what language you want for your next project. please please and please kill words like love, hate from your decision making and choose the right technology for the right job.
On the one hand, academia has lots of influence in deciding what we can use. On the other hand, it just has too many narratives that are not applicable in the real world of problem solving. So technically, it should not be the deciding factor. Once again, choose the right tech for the job at hand and HEY "KILL THE EMOTIONS" and be a real MAN
Biting the hand that feeds IT © 1998–2020