PHP7.0 Version Notes _php instance

The new version of PHP7.0 not only greatly improves performance but also changes a lot in terms of language features, see below:

1. Backwards incompatible changes
Language changes

Changes in variable handling
Indirect variables, properties, and method references are now interpreted from left-to-right semantics. Some examples:

$ $foo [' bar '] [' baz ']//Explain to do ($ $foo) [' Bar '] [' Baz '] $foo $bar [' baz ']//Explain to do ($foo-$bar) [' Baz '] $foo-$bar [' Baz '] ()//interpretation do ($foo-$bar) [' Baz '] () foo:: $bar [' Baz '] ()//Explain Do (foo:: $bar) [' Baz '] ()

To revert to the previous behavior, you need to explicitly increase the parentheses:

${$foo [' Bar '] [' Baz ']} $foo->{$bar [' Baz '}} $foo->{$bar [' Baz ']} () foo::{$bar [' Baz ']} ()

The Global keyword now accepts only simple variables. Like the old

Copy the Code code as follows:
Global $ $foo->bar;

The following wording is now required:

Copy the Code code as follows:
Global ${$foo->bar};

The parentheses around a variable or function call no longer have any effect. For example, the following code, the function call result is passed to a function as a reference

function GetArray () {return [1, 2, 3];} $last = Array_pop (GetArray ());//STRICT standards: Only variables can be passed by reference $last = Array_pop ((GetArray ()));

STRICT standards: Only variables can be passed by reference
Now, with or without parentheses, a strict standard error will be thrown. Previously, there was no hint in the second invocation mode.

Array elements or object properties are automatically installed in the order in which they are created, and now the order of results will be different. For example:

$array = []; $array ["a"] =& $array ["B"]; $array ["b"] = 1;var_dump ($array); Now the result is ["a" and "= 1," b "= 1], and the previous result is [" B " = 1, "A" and "1"

Related RFCs:

Https://wiki.php.net/rfc/uniform_variable_syntax
Https://wiki.php.net/rfc/abstract_syntax_tree

Changes to List ()
List () no longer assigns values in reverse order, for example:

Copy the Code code as follows:
List ($array [], $array [], $array []) = [1, 2, 3];
Var_dump ($array);

Now the result is $array = = [1, 2, 3], not [3, 2, 1]. Note that only the order of assignment changes, and the assignment is still the same (LCTT: the previous list () behavior is assigned from the beginning of the subsequent variable, so that the use of the above will produce a result of [3,2,1]. ）。 For example, a general usage like the following

Copy the Code code as follows:
List ($a, $b, $c) = [1, 2, 3];
$a = 1; $b = 2; $c = 3;

The current behavior is still maintained.

Assigning a value to an empty list () is no longer allowed. The following are all invalid:

List () = $a; list (,,) = $a; list ($x, List (), $y) = $a; list () no longer supports splitting of strings (formerly supported only in some cases)

The following code:

Copy the Code code as follows:
$string = "XY";
List ($x, $y) = $string;

Now the result is: $x = = null and $y = = null (no hint), and the previous result is: $x = = "X" and $y = = "Y".

In addition, list () is now always able to handle objects that implement arrayaccess, such as:

Copy the Code code as follows:
List ($a, $b) = (object) new Arrayobject ([0, 1]);

Now the result is: $a = = 0 and $b = = 1. Previously $a and $b were null.

Related RFCs:

Https://wiki.php.net/rfc/abstract_syntax_tree#changes_to_list
Https://wiki.php.net/rfc/fix_list_behavior_inconsistency

Changes in foreach
The foreach () iteration no longer affects the array internal pointers, which can be accessed through a series of functions such as current ()/next (). For example:

Copy the Code code as follows:
$array = [0, 1, 2];
foreach ($array as & $val) {
Var_dump (current ($array));
}

It will now point to the value int (0) three times. The previous output was int (1), int (2), and bool (false).

When an array is iterated by value, foreach always operates on an array copy, and any array operations in the iteration do not affect the iteration behavior. For example:

Copy the Code code as follows:
$array = [0, 1, 2];
$ref =& $array; necessary to trigger the old behavior
foreach ($array as $val) {
Var_dump ($val);
Unset ($array [1]);
}

All three elements (0 1 2) are now printed, and the previous second element 1 skips (0 2).

When iterating through an array by reference, modifications to the array continue to affect the iteration. Now, however, PHP can better maintain the position within the array when using numbers as keys. For example, you add an array element during a by-reference iteration:

Copy the Code code as follows:
$array = [0];
foreach ($array as & $val) {
Var_dump ($val);
$array [1] = 1;
}

Now the iteration will add the element correctly. The above code output is "int (0) int (1)", which was previously just "int (0)".

Iterating over a normal (non-traversed) object by value or by reference is similar to iterating over an array by reference. This conforms to the previous behavior, except for more precise location management improvements as described in the previous point.

The iterative behavior of the objects that can be traversed remains unchanged.

Related Rfc:https://wiki.php.net/rfc/php7_foreach

Change in Parameter handling
You cannot define two function parameters with the same name. For example, the following method will trigger a compile-time error:

Copy the Code code as follows:
Public function foo ($a, $b, $unused, $unused) {
// ...
}

The code above should be modified using a different parameter name, such as:

Copy the Code code as follows:
Public function foo ($a, $b, $unused 1, $unused 2) {
// ...
}

The Func_get_arg () and Func_get_args () functions no longer return the original value passed to the parameter, but instead return its current value (which may be modified). For example:

Copy the Code code as follows:
function foo ($x) {
$x + +;
Var_dump (Func_get_arg (0));
}

Foo (1);
"2" will be printed instead of "1". The code should be changed to modify only after calling Func_get_arg (s).

Copy the Code code as follows:
function foo ($x) {
Var_dump (Func_get_arg (0));
$x + +;
}

Or you should avoid modifying parameters:

Copy the Code code as follows:
function foo ($x) {
$newX = $x + 1;
Var_dump (Func_get_arg (0));
}

Similarly, exception backtracking no longer shows the original value passed to the function, but the modified value. For example:

Copy the Code code as follows:
function foo ($x) {
$x = 42;
throw new Exception;
}

Foo ("string");
The result of the stack trace is now:

Copy the Code code as follows:
Stack Trace:
#0 file.php (4): foo (42)
#1 {main}

And it used to be:

Copy the Code code as follows:
Stack Trace:
#0 file.php (4): foo (' string ')
#1 {main}

This does not affect the run-time behavior of your code, but it is worth noting that the debugging will be different.

The same restrictions also affect debug_backtrace () and other functions that check function parameters.

Related Rfc:https://wiki.php.net/phpng

Changes in integer processing
An invalid octal representation (containing a number greater than 7) now generates a compilation error. For example, the following code is no longer valid:

$i = 0781; 8 is not a valid octal number!
Previously, an invalid number (and any number after an invalid number) was simply ignored. The previous $i value is 7 because the last two digits are silently discarded.

binary with negative mirror displacement now throws an arithmetic error:

Copy the Code code as follows:
Var_dump (1 >>-1);

Arithmeticerror: Displacement with a negative number
When the left displacement exceeds the integer width, the result is always 0.

Copy the Code code as follows:
Var_dump (1 << 64); Int (0)

The previous result of the preceding code relies on the CPU architecture used. For example, the result on x86 (including x86-64) is an int (1) because its displacement operand is in range.

Similarly, when the number of digits to the right shift exceeds the integer width, the result is always 0 or 1 (dependent on the symbol):

Copy the Code code as follows:
Var_dump (1 >> 64); Int (0)
Var_dump ( -1 >> 64); Int (-1)

Related Rfc:https://wiki.php.net/rfc/integer_semantics

Changes in string handling
A string containing 16 digits will no longer be treated as a number, nor will it be handled specially. See the new behavior in the example:

Copy the Code code as follows:
Var_dump ("0x123" = = "291"); BOOL (FALSE) (formerly True)
Var_dump (Is_numeric ("0x123")); BOOL (FALSE) (formerly True)
Var_dump ("0xe" + "0x1"); Int (0) (formerly 16)
Var_dump (substr ("foo", "0x1")); String (3) "Foo" (formerly "oo")

Note: A number is encountered in an abnormal format
Filter_var () can be used to check whether a string contains a hexadecimal number, or whether the string can be converted to an integer:

$str = "0xFFFF"; $int = Filter_var ($str, Filter_validate_int, Filter_flag_allow_hex); if (false = = = $int) {throw new Excepti On ("Invalid integer!");} Var_dump ($int); Int (65535)

"\u{" with an invalid sequence now causes an error because the Unicode code point escape Format (Unicode codepoint escape Syntax) is added to the double-quote string and here Document:

$str = "\u{xyz}"; Fatal error: Invalid UTF-8 code point escape sequence
To avoid this situation, you need to escape the backslash at the beginning:

$str = "\\u{xyz}"; That's right
However, the "\u" that does not follow {is not affected. The following code does not generate an error, and works as before:

$str = "\u202e"; That's right
Related RFCs:

Https://wiki.php.net/rfc/remove_hex_support_in_numeric_strings
Https://wiki.php.net/rfc/unicode_escape

Change in error handling
There are now two exception classes: Exception and Error. All two of these classes implement a new interface: Throwable. The type indication in the exception handling code may need to be modified to handle this situation.

Some fatal errors and recoverable fatal errors now throw an error instead. Because Error is a Exception-independent class, these exceptions are not captured by an existing Try/catch block.

Recoverable fatal errors are converted to an exception, so they cannot be silently ignored in error handling. In some cases, the type indicates that the failure can no longer be ignored.

Parsing errors now generate an error extension of parseerror. In addition to the previous processing based on return value/Errorgetlast (), the error handling of eval () for some potentially invalid code should be changed to capture ParseError.

The constructor of an inner class always throws an exception when it fails. Previously, some constructors returned NULL or an unusable object.

Some of the error levels of the E_STRICT hint have changed.

Related RFCs:

Https://wiki.php.net/rfc/engine_exceptions_for_php7
Https://wiki.php.net/rfc/throwable-interface
Https://wiki.php.net/rfc/internal_constructor_behaviour
Https://wiki.php.net/rfc/reclassify_e_strict

Other changes in language
Statically invoking a non-static invocation of an incompatible $this context is no longer supported. In this case, the $this is undefined, but the call to it is allowed with an obsolete hint. Example:

Class A {public function test () {var_dump ($this);}} Note: There is no extension from class A class B {public Function Callnonstaticmethodofa () {a::test ()}} (New B)->callnonstaticmethodofa ();

Deprecated: Non-static method A::test () should not be called statically
Hint: undefined variable $this
Null
Note that this only occurs on calls from incompatible contexts. If class B extends from class A, the call is allowed without any hint.

The following class names, interface names, and special names (case sensitive) cannot be used:

bool
Int
Float
String
Null
False
True
This is used in class/interface/trait declarations, Class_alias (), and use statements.

In addition, the following class names, interface names, and special names are reserved for future use, but using fashion does not throw an error:

Resource
Object
Mixed
Numeric
Yield statement structure when used in an expression context, parentheses are no longer required. It is now a right-associative operator with a priority between "print" and "=". In some cases this can lead to different behaviors, such as:

Echo yield-1;
Was previously explained as follows
Echo (yield)-1;
is now explained as follows
Echo Yield (-1);
Yield $foo or die;
Was previously explained as follows
Yield ($foo or die);
is now explained as follows
(yield $foo) or die;
This can be resolved by adding parentheses.

Removed ASP (<%) and script (