📜 ⬆️ ⬇️

PHP 7 beta 1 released

Actually, the first beta version of PHP 7 is presented, a good announcement with changes was previously on Habré (on alpha).

The text of the news on the site published a link to the document UPGRADING, which describes the incompatibility of the "seven". In addition to the DEPRECATED functions and extensions that were thrown out as usual (the mass of SAPI modules disappeared), noticeable changes occurred in the language itself. Below - about some of them.

In order from the official document :

Changes in variable processing
')
1. Indirect references to variables, properties and methods are now understood from left to right. You can restore the previous order with curly braces.
$$foo['bar']['baz'] //   ($$foo)['bar']['baz'] -   ${$foo['bar']['baz']} $foo->$bar['baz'] //   ($foo->$bar)['baz'] -   $foo->{$bar['baz']} $foo->$bar['baz']() //   ($foo->$bar)['baz']() -   $foo->{$bar['baz']}() Foo::$bar['baz']() //   (Foo::$bar)['baz']() -   Foo::{$bar['baz']}() 


2. The global keyword accepts simple variables only. Instead of global $$ foo-> bar, you should write global $ {$ foo-> bar}

3. Brackets around variables or function calls no longer affect behavior. For example, the code where the result of the function is passed by reference:
  function getArray() { return [1, 2, 3]; } $last = array_pop(getArray()); // Strict Standards: Only variables should be passed by reference $last = array_pop((getArray())); // Strict Standards: Only variables should be passed by reference 


now throws the error of strict standards regardless of parentheses (previously it was not in the second call).

4. Array elements or object properties that were automatically created during assignments by reference will now have a different order. Code:
  $array = []; $array["a"] =& $array["b"]; $array["b"] = 1; var_dump($array); 

now it will generate the array ["a" => 1, "b" => 1], whereas it was previously ["b" => 1, "a" => 1].

Changes to list () processing

1. list () now assigns variables in the direct order (earlier - in reverse), for example:
  list($array[], $array[], $array[]) = [1, 2, 3]; var_dump($array); 

will now issue $ array == [1, 2, 3] instead of [3, 2, 1]. Only the order of assignment has changed, i.e. normal use of list () is not affected.

2. Assignments with an empty list () list are prohibited; the following expressions are erroneous:
  list() = $a; list(,,) = $a; list($x, list(), $y) = $a; 


3. list () no longer supports string unpacking (previously supported in some cases). Code:
  $string = "xy"; list($x, $y) = $string; 

will set $ x and $ y to null (without warnings) instead of $ x == "x" and $ y == "y". Moreover, list () is now guaranteed to work with objects that implement the ArrayAccess interface, i.e. This is how it will work:
  list($a, $b) = (object) new ArrayObject([0, 1]); 

Previously, both variables would be null.

Foreach changes

1. Iterations in foreach () no longer affect the internal array pointer, which is accessible through the current () / next () / ... family of functions.
  $array = [0, 1, 2]; foreach ($array as &$val) { var_dump(current($array)); } 

Now it will print int (0) three times. Previously - int (1), int (2), bool (false)

2. During the iteration of arrays by value , foreach now uses a copy of the array, and its changes inside the loop will not affect the behavior of the loop:
  $array = [0, 1, 2]; $ref =& $array; // ,     foreach ($array as $val) { var_dump($val); unset($array[1]); } 

The code will print all the values ​​(0 1 2), previously the second element was dropped - (0 2).

3. When arrays are iterated by reference, changes in the array will affect the loop. It is assumed that PHP will be better to work out a number of cases, for example, adding to the end of the array:
  $array = [0]; foreach ($array as &$val) { var_dump($val); $array[1] = 1; } 

will iterate over the added item. The output will be “int (0) int (1)”, previously there was only “int (0)”.

4. Iteration of ordinary (not Traversable) objects by value or by reference will behave like iteration by reference for arrays. Previously - the same, except for the more accurate positioning from the previous paragraph.

5. Iteration of Traversable objects has not changed.

Changes in the processing of function arguments

1. You can no longer use the same name for the arguments (there will be a compilation error):
  public function foo($a, $b, $unused, $unused) { // ... } 


2. Functions func_get_arg () and func_get_args () will now return the current value (not the original value). For example:
  function foo($x) { $x++; var_dump(func_get_arg(0)); } foo(1); 

will print "2" instead of "1".

3. Similarly, the traces in the exceptions will not display the original values, but already changed:
  function foo($x) { $x = 42; throw new Exception; } foo("string"); 

will now issue:
Stack trace:
#0 file.php(4): foo(42)
#1 {main}


Previously it would be like this:
Stack trace:
#0 file.php(4): foo('string')
#1 {main}


Although this does not affect execution, you should keep this in mind when debugging. The same restriction is now in debug_backtrace () and other functions that examine arguments.

Integer processing changes

1. Incorrect octal numbers will produce a compilation error:
  $i = 0781; // 8 -      


Previously, everything was discarded after an incorrect discharge, and there would be 7 in $ i.

2. Bitwise shifts to negative numbers now cast ArithmeticError:
  var_dump(1 >> -1); // ArithmeticError: Bit shift by negative number 


3. Shifting to the left by a number greater than the bit depth will return 0:
  var_dump(1 << 64); // int(0) 


Previously, the behavior depended on the architecture, on x86 and x86-64, the result was == 1, since the shift was cyclical.

4. Similarly, a shift to the right will give 0 or -1 (depending on the sign):
  var_dump(1 >> 64); // int(0) var_dump(-1 >> 64); // int(-1) 


Error handling changes

1. No more parsing numbers with hexadecimal numbers:
  var_dump("0x123" == "291"); // bool(false) ( true) var_dump(is_numeric("0x123")); // bool(false) ( true) var_dump("0xe" + "0x1"); // int(0) ( 16) var_dump(substr("foo", "0x1")); // string(3) "foo" ( "oo") // Notice: A non well formed numeric value encountered 


filter_var () can be used to check the string for the content of a hexadecimal number or convert it to a regular number:
  $str = "0xffff"; $int = filter_var($str, FILTER_VALIDATE_INT, FILTER_FLAG_ALLOW_HEX); if (false === $int) { throw new Exception("Invalid integer!"); } var_dump($int); // int(65535) 


2. Due to the addition of escape-syntax for Unicode, strings in double quotes and heredoc should take this into account:
  $str = "\u{xyz}"; // Fatal error: Invalid UTF-8 codepoint escape sequence 


Double slash escaping required:
  $str = "\\u{xyz}"; 

Although a simple "\ u" without a follow-up {not affected, and that’s how it will work without changes:
  $str = "\u202e"; 


About new error handling already written here , I will not repeat. From the interesting, you can still add that the constructors of the built-in classes now always throw exceptions, whereas earlier some simply returned null.

Of the other changes, the document now notes the absence of $ this for non-static methods called statically (previously the method used $ this of the calling context).

Replenished, which is logical, the list of names unavailable for classes, traits and interfaces - added bool, int, float, string, null, false, true, and also for future use: resource, object, mixed, numeric.

The yield construct does not require more brackets when used in expressions. He is now a right-associative operator with a priority between "print" and "=>". Therefore, the behavior may change:

  echo yield -1; //    echo (yield) - 1; //    echo yield (-1); 


  yield $foo or die; //    yield ($foo or die); //    (yield $foo) or die; 


It is recommended to force these cases with brackets.

Of the noticeable changes in the standard library of functions, I would only note the deletion of call_user_method () and call_user_method_array (), the rest is not so significant (they threw dl () into php-fpm, renamed and optimized zend_csort cookie and removed the fatal error ob_start inside buffering).

Source: https://habr.com/ru/post/262367/


All Articles