PHP 7, you taken the plunge yet?

I posted this on another forums, but I'm gonna put it here too as I'm just very interested to hear what others think and what your experiences with it so far have been.

I'm just curious -- having upped my server to PHP 7.1 -- how many others out there have made the dive into deploying it real-world. With the 5.x branch having officially ended ALL development apart from security bugfixes as of 31 December 2016, and it facing end of life (aka no more security patches) in almost exactly two years it seems foolhardy -- and outright stupid NOT to be making the transition now.

But then, slopping along on outdated versions with known security bugs seems to be a continuing craze amongst the lazy, feeble minded, and just plain sleazy scam artists out there. Seems like some people want web software to be write once and forget, and frankly that's never been true of any software. Seems like a ridiculously flawed assumption and is why SO many companies seem to get bit in the *** on stuff that's like "we already knew that, why were you still doing that! We've been told for a DECADE to stop doing that!"

In that way, my own transition was relatively seemless since if it works in 5.6 without warnings, it will run in 7 without errors. I'm still evaluating my codebases to see what/where changes and improvements can/should be used just to stretch my hosting dollar a bit further.

For myself getting it up and running was simple since again, howToForge to the rescue. I'm running Debian 8.4 with ISPconfig 3, so after a "apt-get update; apt-get upgrade" it went in pretty cleanly despite having to build from sources since Debian has yet to make an official package for it... and I have a distrust of "custom repositories". Only issue is that ISPConfig dislikes choosing PHP-FPM throwing 500 errors (apache seems to still be looking for PHP 5's FPM) but fastCGI calls PHP-FPM anyways since that's what it is, so I'm really not clear on what that choice in ISPConfig does. Was a lot smoother on the domain on the same server I have set up directly in the Apache .conf files.

Also interested in opinions on the changes and improvements to the language -- and I'm talking the more subtle stuff not the obvious "well it's about huffing time they got rid of the mysql_ nonsense completely!". Though again, would be GREAT if they took the training wheels of mysqli so the feeble minded fools who can't accept that "mysql_ methodology was bad" would stop freaking using the same mind-numbingly dumbass crap under mysqli.

The changes I like are pretty simple.

Array define are a bit overdue. DEFINE is nice when you need the values to be inviolate once set, and don't give a flying purple fish about scope. Being able to make them that are arrays? Lovely.

Null coalescing is great - no more dicking around with isset if you just want to have an alternative value when it isn't. You just

$name = $_POST['username'] ?? 'guest';

Code (markup):

and boom, done. In that same way the spaceship operator is another nice easy shorthand for a common operation... replacing the ternary:

$gtl = $a < $b ? -1 : ($a > b ? 1 : 0);

Code (markup):

with the far simpler...

$gtl= $a <=> b;

Code (markup):

Nice....

The inclusion of typecasting returns is a great example of something overdue -- much like with the changes in ECMAScript 6, this playing fast and loose with typecasting garbage needs to STOP. It's one of the leading causes of mistakes AND possible security holes, and is something a "real" programming language like C would never encounter. Since they gave us typecasing in 7.0, it's also nice to have 7.1 give us the option for a void so that memory isn't wasted allocating space for or accidentally trying to return values from functions that don't return values. (what Modula and Pascal differentiates by calling them procedures, not functions)

I also like that the declaration for function types is Wirth style; typecast of the result AFTER the function name and parameters... though adding said functionality to the language, short of replacing "function" where else were they going to put it?

The catchall "iterable" type is kind of a must-have I guess now that we have typecasting, so it's good 7.1 added it. If the element is arrayTraversable -- REGARDLESS of if it is an actual array, you can use this typecast for it on parameters and results. FEELS like it should be unneccessary, but given the nightmare of trying to add PROPER typecasting to a language that's gone for over a decade without the concept it makes sense.

I'm still not sure the application for anonymous classes, but it looks like JavaScript mutability nutters are trying to drag their garbage into PHP because they don't like how close to how PROPER OOP languages do things in the same manner as "extends". I'm going to have to sit down and write something to actually use it to see if I can even find a reason for it. In that same way I'm not certain I grasp what closure::call is even for, but it looks like something that as someone who learned objects in smalltalk, modula, and object pascal, I'd NEVER be doing in the first place. But then I dislike the 'definition' of closure modern programming seems to have pulled out of the 1960's and poorly translated from Finnish to Japanese and then to English so...

Unicode codepoint string entry? Again, why wasn't this in the language in the first place?!? I'm not AS sold on initlChar's functionality as I'm not certain why you'd use that (much less waste the library space on it) in the first place.

Returns on generators is a good idea too; it's done, SAY it's done... sadly as much as I thought I liked generators when they were introduced in 5.5, and they seem like a good idea, I've yet to encounter a real world scenario where the functionality ACTUALLY seems useful; even if internally on things like SQL fetch operations they're a 1:1 replication of how they work... thing is PHP proviedes those and those are the only type of data I'd be manipulating that way. Passing off to other generators using 'from' (called generator delegation) worries me in terms of it encouraging spaghetti code, but at the same time for large tasks breaking one function into many can help with code clarity. I'm playing the "wait and see" card on how that turns out.

Unserialize? I generally don't manipulate data in that manner, so not sure I'd ever use it...

Also not wild about namespaces in the first place, so not sure I care about their changes to it. To me it's something that if you have objects AND function scope, why do you need it?!? much less that since they may isolate scope but do not actually RESTRICT it, what's the point? Other than being a set of crutches for the people coming in from Java as Oracle continues its trend of "let's destroy EVERYTHING we bought from Sun"...

As a Wirth language fan and assembly language guy, I really like intDiv, but I wish to hell it was an OPERATOR instead of a function. I mean:

$a = intdiv(5, 2); // $a is now 2

is 'cute' and all, but would it have been so hard to copy from the Wirth family languages using a WORD as the operation? I mean in Pascal or Modula the same thing is just:

a := 5 div 2; { a is now 2 }

So I like the idea, it's WAY overdue when it comes to getting rid of the endless pointless dumbass C style 'floor' every time you do something... but the implementation could use a bit of cleaning. It should be an operator/language construct, NOT a function! JUST like / or %.

Array overrides on session_start is interesting, but I'm not quite clear on WHY you would do it -- but that could be that since I use "one index to rule them all" construction, every page and user access on my site is routed through just ONE index.php. If multiple .php were user-facing then I supposed it could be used to track things like which one ran last.

preg_replace_callback_array is powerful and could result in cleaner code, but it seems complex enough that I can see a lot of people throwing hissy fits about it. Of course we're talking about regular expressions so since that's already the case, one extra twist of the knife is par for the course.

Fixing list() for ArrayAccess was another "duh" fix, but PHP 7.1 does something WAY more interesting with list(), it adds the ability to access the indexes so you can assign associative arrays directly to variables -- which means you can ignore some and specifically access other indexes directly instead of having to make a variable for EVERY entry in the array you assign to list().

Though at that point I start to wonder if a bindParam type operator based on indexes might not be a bad idea... but PHP 7.1's new array destructuring is pretty cool in that regard.

$test = [
  [ '007', 'Jimbo' ],
  [ '711', 'Apu' ]
];
foreach ($test as [ $id, $name ]) {

Code (markup):

Oh yeah, I'm down with that.

PHP7 also introduced something that I've seen a few people have problems with... negative string offsets. Before if you passed a negative string offset it was treated as zero... NOW? IF you said $a[-2] you'll get the second character from the END of the string. HANDY -- beats the hell out of playing with substrr -- but could cause migration issues.

Under 7.1 giving CURL HTTP/2 push support really opens the door for a lot of stuff you'd end up either brute forcing with sockets yourself, or diving for something like C to handle. I've not used it yet, and it's not really being pushed as a big feature, but I wonder if it could be one of those silent game-changers just like Microsoft.XMLHTTP was... might go unnoticed for a few years until someone slaps a catchy name like AJAX on it.

Class constants were interesting to begin with, but the lack of means to control their scope negated much of the usefulness since at that point, just put them into global DEFINE -- so I like that they added the ability to set them as private, protected, and public.

7.1 also adds the ability to catch multiple exception types. I've had a few cases in the past where I wished this were possible, so it's good to finally have it!

As to all the stuff deprecated, removed, and axed, I for the most part approve. The only one I'm a little leery of is removing the 'salt' option from password_hash. They seem to think that a system generated value will in fact be more secure than a developer added one, when I had thought the point of it was to layer the user one OVER the system generated as an extra step. On the whole I'm not wild about password_hash in the first place, still using hash() since it offers SHA512 and whirlpool support. My experience with databases the past three and a half decades has taught me never to trust system generated hashes or language choosen cryptology -- yet it seems that is what the PHP dev's are in fact actively encouraging people to do.

In any case, that's my views on it... opinions? What's you folks take on it? Taken the plunge yet? How did that go for you? Any issues putting it in you'd care to share?

It's an important topic, and the sooner we start talking about "death to 5.x" the better, particularly since 5.6 is now officially comatose and on life support so far as the PHP group is concerned.

 

Running 7.0.x on all my servers, haven't upgraded to 7.1 yet (hoping for a plain repository update to avoid having to build it myself), went without a hitch, but then I don't have deprecated code anywhere, so not big surprise. Haven't reality started to play with the brand new functionality, but a couple of the things you mention seem interesting, especially the easier ternary and other checks. Since I use quite a lot of those, it'll be good to get rid of a bit of code.

 

I made the switch to using PDO a couple of years ago, some open source software (they know who they are) still support the old, stoneage mysql_* extension!!!!!

I use prepared statements whenever sending any data to the database so that if I change the source of the data to something supplied by the user I don't accidentally open a security hole.

I'm making sure now that I typecast data everywhere, for new stuff I do, for older bits of code I need to go through and add typecasting.

Give it a little time, when hosts start to upgrade all their servers to PHP 7 on any web development forum you'll start to see many "my site suddenly stopped working" threads