What will PHP 7 bring us?

New major version of PHP is under active development since over a year (including non-public rewrite called phpng) and obviously number of changes still increases. Therefore, I have decided to point out most of important things we can expect.

For this article, I will split them between new features and actions aimed at improving language consistency and cleaning up some rubbish accumulated over the past years.

The name

Short explanation to begin with. The next version after PHP 5 will be PHP 7. The main reason is the fact that PHP 6 already existed and while it never reached stable state, there are many books and resources refering to its name. It was assumed that skipping this number will allow to avoid potential confusion.

Performance

The most notable change is huge speed improvement. Guys from Zend are doing awesome job refactoring Zend Engine and looking for new ways to make code execution faster. It results in even 50% boost in real-life applications, not in synthetic benchmarks.

New features

It should be noted that new major version almost certainly will not bring us highly-desired changes such as renaming functions to end with haystack, needle vs needle, haystack problem once and for all. While it is technically possible, PHP developers don't want to ruin their users' trust breaking too much BC and became another Python 3 (if you know what I mean).

OK, enough talking, let's get down to the facts:

  • Abstract Syntax Tree - this change is under the hood and don't have direct impact on userland code. However, it makes parsing code easier, more flexible and less error prone (it is obvious simplification of the subject, but you probably won't care about the details at this moment).
  • Null Coalesce Operator - new operator ?? (known from some other languages) is introduced. The easiest explanation would be $id = isset($_GET['id']) ? $_GET['id'] : 0; written as $id = $_GET['id'] ?? 0;. Check the original RFC for more details.
  • Unicode Codepoint Escape Syntax - introduces syntax to escape Unicode codepoint (e.g. \u{202E})
  • Closure::call() method has been added - it is a feature known from JavaScript (or rather ECMAScript), which allows to bind variables to closures at call-time
  • Error call to a member function of a non-object is now catchable
  • unserialize() allows to either completely prohibit restoring objects or restrict the objects being restored to a whitelist of objects

Cleanups

  • mysql_* functions are no longer available by default, because ext/mysql has been removed from core and will be moved to PECL
  • ext/ereg (ereg_* functions) has been removed and will be migrated to PECL as well
  • Uniform Variable Syntax - variable syntax in PHP 7 is more consistent and allows for more advanced expressions. This change introduces some backwards compatibility breaks in edge cases, but they can be avoided by using curly braces, so the code is parsed the same way in PHP 5 and 7. Click on the link to check real-life examples.
  • Some inconsistences in handling integers on different platforms are fixed (more details)
  • String support for list() has been removed as it has been introduced unintentionally and might cause unexpected results (more details)
  • Alternative PHP tags, namely <%, <%= (ASP tags) and <script language="php">, are removed
  • Support for multiple default clauses in switch has been removed
  • Support for comments indicated with # in INI files has been removed
  • $is_dst parameter of the mktime() and gmmktime() functions has been removed
  • Support for assigment of new by reference has been dropped (write $obj = new ClassName instead of $obj =& new ClassName)
  • e (eval) modifier for preg_replace() has been removed. preg_replace_callback() should be used instead
  • PDO::PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT driver option has been removed - more general PDO::ATTR_EMULATE_PREPARES should be used instead
  • CN_match and SNI_server_name stream context options are removed
  • Scoped calls of non-static methods from incompatible $this context are no longer supported (more details)
  • Support for string category names in setlocale() has been dropped (use LC_* constant instead of e.g. 'LC_ALL' string)
  • Support for unsafe CURL uploads has been removed
  • Following php.ini directives have been removed: iconv.input_encoding, iconv.output_encoding, iconv.internal_encoding, mbstring.http_input, mbstring.http_output, mbstring.internal_encoding and xsl.security_prefs
  • Following functions are removed: dl (only on fpm-fcgi SAPI), set_magic_quotes_runtime, magic_quotes_runtime, set_socket_blocking, mcrypt_generic_end, mcrypt_ecb, mcrypt_cbc, mcrypt_cfb, mcrypt_ofb, datefmt_set_timezone_id and IntlDateFormatter::setTimeZoneID

Conclusion

Personally, I find all changes mentioned above as a very good message for everyone interested in PHP development. More consistent language means less quirks to remember and allows to write code more effeciently.

Moreover, I think it's a great starting point for potential new features. Focusing on cleanup, internal and userland as well, is very important aspect, as the new major version is probably the only oportunity to do this in next about ten years.

Note: it is my first article written in English, so I would be very glad for being forgiving (in linguistic aspect, not meritorical, of course!) and pointing out eventual language mistakes.

3 komentarze do “What will PHP 7 bring us?

  1. „breaking too much BC ”
    BC – the beloved and hated at the same time god of everything that is connected with Web… That odd creature is wreaking havoc everywhere, not only in PHP (look at ES6 and the conception of one JS, which includes 2 JS-es: ES5, in 2 flavours and ES6, in 4 flavours – being of cours one, unified language).
    But yeah, breaking too much BC would kill some things…

    „Support for unsafe CURL uploads has been removed”
    Isn’t it funny that it was supported at all?

    „mysql_* functions are no longer available by default, because ext/mysql has been removed from core and will be moved to PECL”
    At last… but why will it be moved to PECL? ‚Removing’ means removing, not moving (note that ‚re’ at the beginning!)

    • Sobak pisze:

      But yeah, breaking too much BC would kill some things…

      Yep, it would. For example kill PHP :P If PHP would change drastically to become new, shiny language with consitent library etc, what would stop people from switching to another technology? How whould it be better comparing to them, if it wouldn’t no longer be the same language?

      Python already tested such approach and I think conclusions are clear. Years after 3.0 release, there are still tons of code which wasn’t and won’t be upgraded. Python did even more insane thing, as their syntax is not only backwards incompatibile – their also broke forward compatbility.

      At last… but why will it be moved to PECL? ‚Removing’ means removing, not moving (note that ‚re’ at the beginning!)

      Perhaps such extension would be created sooner or later. Removing mysql_* functions is a big break, undeniably. I think it’s better when PHP.net have at least minimal control over that.

      • >Python already tested such approach and I think conclusions are clear. Years after 3.0 release, there are still tons of code which wasn’t and won’t be upgraded.

        Yep, what Python guys made was a disaster IMHO, but Python was already good and consistent language (in opposite to PHP) and new version din’t introduce anything really special. They fixed something that was good and as a result now it’s worst than before. It’s true that a lot of software was’t ported. Mess.

        Making a new version of a programming language is always risky, C++11 was made in 2011 and still isn’t popular (yeah, compilers support), Perl 6 was introduced 15 years ago and I don’t even know if they finally released an interpreter for it.

        Anyway I believe that it can be made correctly.

        Looking at those changes that PHP6 will bring, I don’t think that they are huge enough to update number by one :)

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *