PHP 7.0 arrives, so go forth and upgrade if you dare

Re: Changes in PHP 7

Really?

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.

Re: just my 2 cents...

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

Re: just my 2 cents...

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.

Re: just my 2 cents...

If you can't support multiple versions of PHP (i.e. 5.4.max, 5.6.max, 7.0.max), you _ARE_ a pretty terrible hosting service.

Re: just my 2 cents...

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.

Re: just my 2 cents...

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.

Re: Not backwards compatible can cause a lot of problems

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.

Re: Not backwards compatible can cause a lot of problems

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

Re: Not backwards compatible can cause a lot of problems

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

Re: Not backwards compatible...

Depends if you have a team of 15 PHP developers really I'd think (the facebook dilemma). It may or may not be the best choice but it's up there. Nobody ever got fired for doing it as they say.

Re: Not backwards compatible...

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!

Re: Not backwards compatible...

@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 decide to rewrite, you will find that for something that works the way you are used to dealing with, your options are limited to Perl, Python, Ruby, and NodeJS (Javascript). My own choice would be Python for its wide support, large selection of frameworks, and great flexibility.

Not a lot of new stuff seems to be getting written in Perl these days, Ruby is mainly used for Rails, and it's hard to say if Rails really suits your needs (Rails popularity seems to be declining due to changes in the way people are designing stuff these days). NodeJS is a framework rather than a language (it uses Javascript), and while it is "hot" at the moment it's hard to say whether NodeJS works the way you need it to work. What I can say about Python is that whatever it is you need to do, you can be sure that you can do it with Python without having to force fit your application into one specific framework.

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.

Re: Not backwards compatible...

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

Re: WTF is a "spaceship operator"?

I can't see that the 'spaceship' operator helps in any great way other than to allow people to write 'clever' code which obfuscates what it does and leaves a maintenance programmer wondering if it might just have been a typo.

Re: WTF is a "spaceship operator"?

So it's like a minus sign?

Re: They had to release it as v7

Cos perl6 will be out in a few weeks

'cos we never heard that before! ;-)

Re: They had to release it as v7

Not really.

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.

Re: They had to release it as v7

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

This is three and a half years old but I've just seen this.

Errrrrrrr gross!