What to expect when you expect a child: PHP 7, part 1

This is the first part of our miniseries of “What to expect from PHP7”. Read part 2

As many of you probably know, the RFC was adopted to agree on the name of the next major version of PHP, which will be called PHP7. You can read about it in my PHP5 timeline .

Regardless of your feelings about this topic, PHP7 is a fait accompli, and it will come this year ! The RFC with the PHP7.0 release timeline was almost unanimous (32 to 2), now the developers have approached the feature freezing stage, and we will see the first release candidate (RC) in the middle of June.

But what does all this mean for us, ordinary developers? Now we see a huge reluctance of web hosting to move in the direction of new versions 5.x. Will a major update breaking backward compatibility lead to even slower movement?
')
Answer: we'll see. Keep reading and learn the details.

Most of the problems with incorrect behavior in unusual situations have been fixed. In addition, performance and troubleshooting are key areas for this release.

Let's get into the details.

Nonconformity fixes

Unfortunately, needle/haystack tickets were never resolved. However, two very important RFCs have passed. So do not lose hope for the arrival of the much-needed sequence and the expected syntax.

The largest (and most invisible) was the addition of an abstract syntax tree (Abstract Syntax Tree - AST), which is an intermediate representation of the code at compile time. With AST, core developers will be able to better handle borderline cases, eliminate inconsistencies in behavior, and also pave the way for amazing things in the future, for example, it will be possible to create even more efficient accelerators.

A single variable syntax was also introduced, which can cause many problems with the migration to PHP7. It solves numerous inconsistencies in the calculation of expressions. For example, the ability to call anonymous functions bound to parameters via ($object->closureProperty)() , also adds the ability to call chains of static methods:

 class foo { static $bar = 'baz'; } class baz { static $bat = 'Hello World'; } baz::$bat = function () { echo "Hello World"; }; $foo = 'foo'; ($foo::$bar::$bat)(); 

However, something has changed. In particular, the semantics of using variable variables / properties.

Before PHP7, $obj->$properties['name'] was access to a property whose name was included in the value stored by the name key of the $properties array. Now, access will be made to the value by the name key of the array, which, in turn, is determined by the value of the $properties parameter in the object.

Or, to be more brief, if we accept this statement:

 $obj->$properties['name'] 

That in PHP5.6, it will be interpreted as:

 $obj->{$properties['name']} 

And in PHP 7:

 {$obj->$properties}['name'] 

Although the use of variable variables is usually a borderline case, and quite disapproved by the community, the variable parameters are much more rare in my practice. However, you can easily do without migration problems if you use curly braces (as in the examples above) to provide similar behavior between PHP5.6 and PHP7.

Performance

The biggest reason for switching to PHP7 is its performance, which is primarily due to its characteristics phpng . Increased productivity can be a decisive factor for the rapid transition to the 7th version of small hosters, because they will be able to accommodate more clients on the same equipment.

Currently, things are as follows: PHP7 is on par with HHVM, written by Facebook, which works as a Just In Time (JIT) compiler that translates PHP code into machine instructions.

PHP7 does not have a JIT compiler, although there have been many discussions about it. It is unclear what performance gains this step will give, but I am sure it will be interesting to see if someone still decides to do it!

In addition to performance, a nice side effect of optimizing the internal data structure will be significant memory savings.

Backward compatibility changes

Of course, core developers tried very hard not to break backward compatibility with previous versions, but, unfortunately, it is not always possible to do this as you move the language forward, there will definitely be those who are not happy .

However, as well as the change in behavior due to the introduction of Uniform Variable Syntax, most of the innovations are minor, for example, trapped fatal errors when calling a method on a non-object :

 set_error_handler(function($code, $message) { var_dump($code, $message); }); $var = null; $var->method(); echo $e->getMessage(); // Fatal Error: Call to a member function method() on null echo "Hello World"; // Still runs 

In addition, the APS and script tags have been removed, you can no longer use <% and <%= , or `<script language="php”>` and their closing tags %>

Other, much more serious changes are in the RFC about removing ALL outdated (deprecated) functionality .

Of particular note is the exclusion from the standard delivery of the extension of posix-compatible regular expressions ext / ereg (not recommended for use in 5.3) and the old ext / mysql extension (replaced by the new one in 5.5).

One of the other minor changes is the prohibition of using multiple default in the switch . PHP to version 7 allowed to do so:

 switch ($expr) { default: echo "Hello World"; break; default: echo "Goodbye Moon!"; break; } 

This will only execute the latter. PHP7 will generate an error:

 Fatal error: Switch statements may only contain one default clause 

New opportunities

Of course, we will cope with the consequences of changes that break backward compatibility. We value performance. But even more we enjoy the new features! The new functionality is what makes every release a pleasure, and PHP7 is no exception.

Scalar type-hint and return values

I'm going to start with the most controversial point that was added in PHP7: Scalar Type Hints . The RFC on the addition of this feature almost passed the vote, but the author was so influenced by the controversy that he decided to leave the PHP development, and also removed the RFC from the vote. This was followed by a few more, with competing implementations. There were a lot of social unrest that eventually ended (positively) and the original version of the RFC was adopted.

For you end users, this means that you can use type-hint with scalar values. Namely: int , float , string and bool . By default, the function works in a nonstrict mode, which means they will simply cast the original type to the value specified in the type hint. For example, if you pass int(1) to a function that requires a non-integer number, then it will be cast to float(1.0) . And vice versa: passing to a function that requires an integer, float(1.5) , then the value int(1) will come. Example:

 function sendHttpStatus(int $statusCode, string $message) { header('HTTP/1.0 ' .$statusCode. ' ' .$message); } sendHttpStatus(404, "File Not Found"); // integer and string passed sendHttpStatus("403", "OK"); // string "403" coerced to int(403) 

You can enable declare(strict_types=1); strong typing declare(strict_types=1); at the top of the file and it guarantees you that any function call made in this file will strictly adhere to a certain type. This will happen in the file where declare called, and not in the file where the called function was defined.

If the types do not match, this will lead to the release of the fatal error being caught:

 declare(strict_types=1); //      sendHttpStatus(404, "File Not Found"); // integer  string  sendHttpStatus("403", "OK"); // Catchable fatal error: Argument 1 passed to sendHttpStatus() must be of the type integer, string given 

PHP7 also supports a return type , which can take all the same types as arguments. The syntax will be as in hack , a colon with an argument suffix before the bracket:

 function isValidStatusCode(int $statusCode): bool { return isset($this->statuses[$statusCode]); } 

In this example : bool indicates that the function will return a boolean value.

The same rules that apply to type-hint work here too in the case of a strict mode declaration.

Combined comparison operator

My favorite addition to PHP7 is the addition of a combined comparison operator , <=> , also known as the Spaceship operator. I may seem biased, but he is really cool, and he combines well with the operators > and < .

Effectively works as strcmp() or version_compare() , returning -1 if the left operand is less than the right, 0 if they are equal, and 1 if the left is more than the right. Its main difference from functions is that it can be used on any two operands, and not only on primitives.

Its most common use is callback sorts:

 // Pre Spacefaring^W PHP 7 function order_func($a, $b) { return ($a < $b) ? -1 : (($a > $b) ? 1 : 0); } // Post PHP 7 function order_func($a, $b) { return $a <=> $b; } 

Further

We analyzed some of the most important fixes for behavior inconsistencies and looked at two new features in PHP7.

In the next post, we will look at six other major innovations in PHP7 that you will definitely want to know.

PS And while you're waiting, why not share your thoughts on what will be most expected in PHP7? Or maybe there are things that I would not like to see in the language?