Story 2014-09-21 2SPM PHP6 abandoned, going straight to PHP7

PHP6 abandoned, going straight to PHP7

in code on (#2SPM)
In 2005, work began on a project headed by Andrei Zmievski to bring native Unicode support to the language by embedding the International Components for Unicode (ICU) library and internally representing strings as UTF-16. Because this project would lead to major internal and user-affecting changes, it was planned to be the next major PHP version (i.e. version 6) along with a few other features.

By using UTF-16 as default encoding, developers would need to convert the code and all input (e.g. data from requests, database, etc.) from one encoding to UTF-16 and back again. This conversion takes a lot of CPU time, memory (to store the much larger strings), and creates a higher complexity in the implementation due to the increased need to detect the proper encoding for the situation. In light of all of this and the relatively small gain, many contributors became unwilling to use "trunk" as their main development branch and instead either using the stable 5.2/5.3 branches or refusing to do development at all. This shortage of developers led to delays in the project.

In 2009, PHP 5.3 release with many non-Unicode features back-ported from PHP6, most notably namespaces. This became the widely used, stable version of PHP, and in March 2010, the PHP6 project was officially abandoned, and instead PHP 5.4 was prepared containing most remaining non-Unicode features from PHP 6, such as traits and closure re-binding.

Why Jump to PHP7?

After a vote in July of 2014, it was officially decided that the next major release would be called PHP7. The primary reason for even considering the name is the widely-known existence of the previous failed attempt of a new major release, and the existence of numerous books and other resources which already referred to the previous PHP 6. To address potential confusion, there was an RFC (i.e. request for comments) and a vote on whether or not to reuse this name.

Read the rest at the Halls of Valhalla.
Reply 8 comments

Will Pipedot be upgrading to PHP 7? (Score: 0)

by Anonymous Coward on 2014-09-21 12:40 (#2SPV)

Will Pipedot be upgrading to PHP 7?

Re: Will Pipedot be upgrading to PHP 7? (Score: 2, Informative)

by on 2014-09-21 19:06 (#2SQ4)

Unless it has a really useful feature or two, I'll probably keep the site on Ubuntu Trusty (a LTS release.)

It's time for Perl 7! (Score: 2, Insightful)

by Anonymous Coward on 2014-09-21 12:48 (#2SPW)

It's time for the Perlers to do the same thing. Instead of extended Perl 5 for decades, it's time for Perl 7. Perl 6 is a failure, and always will be. The sooner the Perl community admits this, the sooner Perl can move into the future.

Re: It's time for Perl 7! (Score: 2, Interesting)

by on 2014-09-22 11:02 (#2SR3)

If Perl 7 did nothing other than deal easily with UTF-8 characters, that would be good enough and well-worth it. Non unicode support is becoming a deathknell for a lot of applications, and perl should be smart enough to deal with things like this by now. I also wouldn't shed a tear if they decided to give up on some of the retrofit OO stuff they've added on - not sure it was ever a good fit or worth it, and if you want object oriented you can always use python instead.

Re: It's time for Perl 7! (Score: 0)

by Anonymous Coward on 2014-09-22 19:46 (#2SSG)

That's a not-so-subtle Slashcode dig, isn't it. :)

Re: It's time for Perl 7! (Score: 1)

by on 2014-09-22 21:03 (#2SSH)

Ha ha! Hadn't even thought of that, but you're absolutely right. But more personally, I've had a hell of a time with some scripts just because of UTF8 issues. Annoying.

I tried to think of something positive (Score: -1, Offtopic)

by Anonymous Coward on 2014-09-21 12:53 (#2SPX)

but I can't. So I won't.

utf-16 (Score: 1)

by on 2014-09-23 06:39 (#2STD)

Doesn't Qt also store its strings as UTF-16 internally? I haven't seen complaints about that.