sigmasternchen/php-doc-en
1
0
Fork 0
mirror of https://github.com/sigmasternchen/php-doc-en synced 2025-03-15 16:38:54 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Split the incompatible section into separate files.

Browse source 
In the longer run, I'd prefer to have them appear as nested entries in the top
level 7.0 migration guide ToC, as the backward incompatible page is going to be
**huge**, but I can't get Docbook to give me that right now, and I'm not sure
there is a way short of hacking PhD.

Something to discuss.

git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@337334 c90b9560-bf6c-de11-be94-00142212c4b1
This commit is contained in:
Adam Harvey 2015-08-09 01:14:28 +00:00
parent d12bfab7d6
commit 285e7e31e5
4 changed files with 660 additions and 587 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

591
appendices/migration70/incompatible.xml
View file

@ -2,594 +2,11 @@
<!-- $Revision$ -->
<sect1 xml:id="migration70.incompatible">
<title>Backward Incompatible Changes</title>
<simpara>
Although most existing PHP 5 code should work without changes, please take
note of some backward incompatible changes:
</simpara>
<title>Backward incompatible changes</title>
<sect2 xml:id="migration70.incompatible.variable-handling">
<title>Changes to variable handling</title>
<para>
PHP 7 now uses an abstract syntax tree when parsing source files. This has
permitted many improvements to the language which were previously
impossible due to limitations in the parser used in earlier versions of
PHP, but has resulted in the removal of a few special cases for consistency
reasons, which has resulted in backward compatibility breaks. These cases
are detailed in this section.
</para>
<sect3 xml:id="migration70.incompatible.variable-handling.indirect">
<title>
Changes to the handling of indirect variables, properties, and methods
</title>
<para>
Indirect access to variables, properties, and methods will now be
evaluated strictly in left-to-right order, as opposed to the previous mix
of special cases. The table below shows how the order of evaluaiton has
changed.
</para>
<para>
<table>
<title>Old and new evaluation of indirect expressions</title>
<tgroup cols="3">
<thead>
<row>
<entry>Expression</entry>
<entry>PHP 5 interpretation</entry>
<entry>PHP 7 interpretation</entry>
</row>
</thead>
<tbody>
<row>
<entry>
<code>$$foo['bar']['baz']</code>
</entry>
<entry>
<code>${$foo['bar']['baz']}</code>
</entry>
<entry>
<code>($$foo)['bar']['baz']</code>
</entry>
</row>
<row>
<entry>
<code>$foo-&gt;$bar['baz']</code>
</entry>
<entry>
<code>$foo-&gt;{$bar['baz']}</code>
</entry>
<entry>
<code>($foo-&gt;$bar)['baz']</code>
</entry>
</row>
<row>
<entry>
<code>$foo-&gt;$bar['baz']()</code>
</entry>
<entry>
<code>$foo-&gt;{$bar['baz']}()</code>
</entry>
<entry>
<code>($foo-&gt;$bar)['baz']()</code>
</entry>
</row>
<row>
<entry>
<code>Foo::$bar['baz']()</code>
</entry>
<entry>
<code>Foo::{$bar['baz']}()</code>
</entry>
<entry>
<code>(Foo::$bar)['baz']()</code>
</entry>
</row>
</tbody>
</tgroup>
</table>
</para>
<para>
Code that used the old right-to-left evaluation order must be rewritten to
explicitly use that evaluation order with curly braces (see the above
middle column). This will make the code both forwards compatible with PHP
7.x and backwards compatible with PHP 5.x.
</para>
</sect3>
<sect3 xml:id="migration70.incompatible.variable-handling.list">
<title>Changes to <function>list</function> handling</title>
<sect4 xml:id="migration70.incompatible.variable-handling.list.order">
<title>
<function>list</function> no longer assigns variables in reverse order
</title>
<para>
<function>list</function> will now assign values to variables in the
order they are defined, rather than reverse order. In general, this only
affects the case where <function>list</function> is being used in
conjunction with the array <code>[]</code> operator, as shown below:
</para>
<informalexample>
<programlisting role="php">
<![CDATA[
<?php
list($a[], $a[], $a[]) = [1, 2, 3];
var_dump($a);
?>
]]>
</programlisting>
&example.outputs.5;
<screen>
<![CDATA[
array(3) {
[0]=>
int(3)
[1]=>
int(2)
[2]=>
int(1)
}
]]>
</screen>
&example.outputs.7;
<screen>
<![CDATA[
array(3) {
[0]=>
int(1)
[1]=>
int(2)
[2]=>
int(3)
}
]]>
</screen>
</informalexample>
<para>
In general, it is recommended not to rely on the order in which
<function>list</function> assignments occur, as this is an implementation
detail that may change again in the future.
</para>
</sect4>
<sect4 xml:id="migration70.incompatible.variable-handling.list.empty">
<title>Empty <function>list</function> assignments have been removed</title>
<para>
<function>list</function> constructs can no longer be empty, or contain
empty variables. The following are no longer allowed:
</para>
<informalexample>
<programlisting role="php">
<![CDATA[
<?php
list() = $a;
list(,,) = $a;
list($x, list(), $y) = $a;
?>
]]>
</programlisting>
</informalexample>
</sect4>
<sect4 xml:id="migration70.incompatible.variable-handling.list.string">
<title><function>list</function> cannot unpack <type>string</type>s</title>
<para>
<function>list</function> can no longer unpack <type>string</type>
variables. <function>str_split</function> should be used instead.
</para>
</sect4>
</sect3>
<sect3 xml:id="migration70.incompatible.variable-handling.array-order">
<title>
Array ordering when elements are automatically created during by reference
assignments has changed
</title>
<para>
The order of the elements in an array has changed when those elements have
been automatically created by referencing them in a by reference
assignment. For example:
</para>
<informalexample>
<programlisting role="php">
<![CDATA[
<?php
$array = [];
$array["a"] =& $array["b"];
$array["b"] = 1;
var_dump($array);
?>
]]>
</programlisting>
&example.outputs.5;
<screen>
<![CDATA[
array(2) {
["b"]=>
&int(1)
["a"]=>
&int(1)
}
]]>
</screen>
&example.outputs.7;
<screen>
<![CDATA[
array(2) {
["a"]=>
&int(1)
["b"]=>
&int(1)
}
]]>
</screen>
</informalexample>
</sect3>
<sect3 xml:id="migration70.incompatible.variable-handling.global">
<title>&global; only accepts simple variables</title>
<para>
<link linkend="language.variables.variable">Variable variables</link> can
no longer be used with the &global; keyword. The curly brace syntax can be
used to emulate the previous behaviour if required:
</para>
<informalexample>
<programlisting role="php">
<![CDATA[
<?php
function f() {
// Valid in PHP 5 only.
global $$foo->bar;
// Valid in PHP 5 and 7.
global ${$foo->bar};
}
?>
]]>
</programlisting>
</informalexample>
<para>
As a general principle, using anything other than a bare variable with
&global; is discouraged.
</para>
</sect3>
<sect3 xml:id="migration70.incompatible.variable-handling.parentheses">
<title>
Parentheses around function parameters no longer affect behaviour
</title>
<para>
In PHP 5, using redundant parentheses around a function parameter could
quiet strict standards warnings when the function parameter was passed by
reference. The warning will now always be issued.
</para>
<informalexample>
<programlisting role="php">
<![CDATA[
<?php
function getArray() {
return [1, 2, 3];
}
function squareArray(array &$a) {
foreach ($a as &$v) {
$v **= 2;
}
}
// Generates a warning in PHP 7.
squareArray((getArray()));
?>
]]>
</programlisting>
&example.outputs;
<screen>
<![CDATA[
Notice: Only variables should be passed by reference in /tmp/test.php on line 13
]]>
</screen>
</informalexample>
</sect3>
</sect2>
<sect2 xml:id="migration70.incompatible.foreach">
<title>Changes to &foreach;</title>
<para>
Minor changes have been made to the behaviour of the &foreach; control
structure, primarily around the handling of the internal array pointer and
modification of the array being iterated over.
</para>
<sect3 xml:id="migration70.incompatible.foreach.array-pointer">
<title>&foreach; no longer changes the internal array pointer</title>
<para>
Prior to PHP 7, the internal array pointer was modified while an array was
being iterated over with &foreach;. This is no longer the case, as shown
in the following example:
</para>
<informalexample>
<programlisting role="php">
<![CDATA[
<?php
$array = [0, 1, 2];
foreach ($array as &$val) {
var_dump(current($array));
}
?>
]]>
</programlisting>
&example.outputs.5;
<screen>
<![CDATA[
int(1)
int(2)
bool(false)
]]>
</screen>
&example.outputs.7;
<screen>
<![CDATA[
int(0)
int(0)
int(0)
]]>
</screen>
</informalexample>
</sect3>
<sect3 xml:id="migration70.incompatible.foreach.by-value">
<title>&foreach; by-value operates on a copy of the array</title>
<para>
When used in the default by-value mode, &foreach; will now operate on a
copy of the array being iterated rather than the array itself. This means
that changes to the array made during iteration will not affect the values
that are iterated.
</para>
</sect3>
<sect3 xml:id="migration70.incompatible.foreach.by-ref">
<title>&foreach; by-reference has improved iteration behaviour</title>
<para>
When iterating by-reference, &foreach; will now do a better job of
tracking changes to the array made during iteration. For example,
appending to an array while iterating will now result in the appended
values being iterated over as well:
</para>
<informalexample>
<programlisting role="php">
<![CDATA[
<?php
$array = [0];
foreach ($array as &$val) {
var_dump($val);
$array[1] = 1;
}
?>
]]>
</programlisting>
&example.outputs.5;
<screen>
<![CDATA[
int(0)
]]>
</screen>
&example.outputs.7;
<screen>
<![CDATA[
int(0)
int(1)
]]>
</screen>
</informalexample>
</sect3>
<sect3 xml:id="migration70.incompatible.foreach.object">
<title>Iteration of non-<classname>Traversable</classname> objects</title>
<para>
Iterating over a non-<classname>Traversable</classname> object will now
have the same behaviour as iterating over by-reference arrays. This
results in the
<link linkend="migration70.incompatible.foreach.by-ref">improved behaviour when modifying an array during iteration</link>
also being applied when properties are added to or removed from the
object.
</para>
</sect3>
</sect2>
<sect2 xml:id="migration70.incompatible.php-tags">
<title>ASP and script PHP tags removed</title>
<para>
Support for using ASP and script tags to delimit PHP code has been removed.
The affected tags are:
</para>
<table>
<title>Removed ASP and script tags</title>
<tgroup cols="2">
<thead>
<row>
<entry>Opening tag</entry>
<entry>Closing tag</entry>
</row>
</thead>
<tbody>
<row>
<entry><code>&lt;%</code></entry>
<entry><code>%&gt;</code></entry>
</row>
<row>
<entry><code>&lt;%=</code></entry>
<entry><code>%&gt;</code></entry>
</row>
<row>
<entry><code>&lt;script language="php"&gt;</code></entry>
<entry><code>&lt;/script&gt;</code></entry>
</row>
</tbody>
</tgroup>
</table>
</sect2>
<sect2 xml:id="migration70.incompatible.func-parameters">
<title>Functions can't have more than one parameter with the same name</title>
<para>
It is no longer possible to define two function parameters with the same name.
For example, the following method will trigger <constant>E_COMPILE_ERROR</constant>:
</para>
<informalexample>
<programlisting role="php">
<![CDATA[
<?php
function foo($a, $b, $unused, $unused) {
//
}
?>
]]>
</programlisting>
</informalexample>
</sect2>
<sect2 xml:id="migration70.incompatible.http-raw-post-data">
<title>$HTTP_RAW_POST_DATA removal</title>
<para>
<varname>$HTTP_RAW_POST_DATA</varname> is no longer available. Use the
<literal>php://input</literal> stream instead.
</para>
</sect2>
<sect2 xml:id="migration70.incompatible.ini-comments">
<title>Drop #-style comments in INI files</title>
<para>
Support for <literal>#</literal>-style comments in INI files has been dropped. <literal>;</literal>
is the only possible comment indicator now.
</para>
</sect2>
<sect2 xml:id="migration70.incompatible.invalid-octals">
<title>Invalid Octal Literals</title>
<para>
Previously, octal literals that contained invalid numbers were silently
truncated (<literal>0128</literal> was taken as <literal>012</literal>).
Now, an invalid octal literal will cause a parse error.
</para>
</sect2>
<sect2 xml:id="migration70.incompatible.removed-functions">
<title>Removed functions</title>
<para>
Following functions have been removed from PHP:
</para>
<itemizedlist>
<listitem>
<simpara>
<function>call_user_method</function> and <function>call_user_method_array</function>
</simpara>
</listitem>
<listitem>
<simpara>
<function>mcrypt_generic_end</function> alias in favor of <function>mcrypt_generic_deinit</function>
</simpara>
</listitem>
<listitem>
<simpara>
deprecated <function>mcrypt_ecb</function>,
<function>mcrypt_cbc</function>, <function>mcrypt_cfb</function> and
<function>mcrypt_ofb</function> in favor of <function>mcrypt_decrypt</function>
with an <literal>MCRYPT_MODE_*</literal>
</simpara>
</listitem>
<listitem>
<simpara>
deprecated aliases <function>datefmt_set_timezone_id</function> and
<methodname>IntlDateFormatter::setTimeZoneID</methodname> in favor of
<function>datefmt_set_timezone</function> or <methodname>IntlDateFormatter::setTimeZone</methodname>
</simpara>
</listitem>
<listitem>
<simpara>
<function>set_magic_quotes_runtime</function> and its alias <function>magic_quotes_runtime</function>
</simpara>
</listitem>
<listitem>
<simpara>
<function>set_socket_blocking</function> in favor of its alias <function>stream_set_blocking</function>
</simpara>
</listitem>
<listitem>
<simpara>
<function>dl</function> from fpm-fcgi
</simpara>
</listitem>
<listitem>
<simpara>
<function>imagepsbbox</function>, <function>imagepsencodefont</function>,
<function>imagepsextendedfont</function>, <function>imagepsfreefont</function>,
<function>imagepsloadfont</function>, <function>imagepsslantfont</function>,
<function>imagepstext</function> due to T1Lib support removal
</simpara>
</listitem>
</itemizedlist>
</sect2>
<sect2 xml:id="migration70.incompatible.removed-directives">
<title>Removed INI directives</title>
<para>
Following &php.ini; directives have been removed from PHP:
</para>
<itemizedlist>
<listitem>
<simpara>
<link linkend="ini.always-populate-raw-post-data"><parameter>always_populate_raw_post_data</parameter></link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="ini.asp-tags"><parameter>asp_tags</parameter></link>
</simpara>
</listitem>
<listitem>
<simpara>
<parameter>xsl.security_prefs</parameter> - use <methodname>XsltProcessor::setSecurityPrefs</methodname>
instead
</simpara>
</listitem>
</itemizedlist>
</sect2>
&appendices.migration70.incompatible.variable-handling;
&appendices.migration70.incompatible.foreach;
&appendices.migration70.incompatible.other;
</sect1>
<!-- Keep this comment at the end of the file

134
appendices/migration70/incompatible/foreach.xml Normal file
View file

@ -0,0 +1,134 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- $Revision$ -->
<sect2 xml:id="migration70.incompatible.foreach">
<title>Changes to &foreach;</title>
<para>
Minor changes have been made to the behaviour of the &foreach; control
structure, primarily around the handling of the internal array pointer and
modification of the array being iterated over.
</para>
<sect3 xml:id="migration70.incompatible.foreach.array-pointer">
<title>&foreach; no longer changes the internal array pointer</title>
<para>
Prior to PHP 7, the internal array pointer was modified while an array was
being iterated over with &foreach;. This is no longer the case, as shown
in the following example:
</para>
<informalexample>
<programlisting role="php">
<![CDATA[
<?php
$array = [0, 1, 2];
foreach ($array as &$val) {
var_dump(current($array));
}
?>
]]>
</programlisting>
&example.outputs.5;
<screen>
<![CDATA[
int(1)
int(2)
bool(false)
]]>
</screen>
&example.outputs.7;
<screen>
<![CDATA[
int(0)
int(0)
int(0)
]]>
</screen>
</informalexample>
</sect3>
<sect3 xml:id="migration70.incompatible.foreach.by-value">
<title>&foreach; by-value operates on a copy of the array</title>
<para>
When used in the default by-value mode, &foreach; will now operate on a
copy of the array being iterated rather than the array itself. This means
that changes to the array made during iteration will not affect the values
that are iterated.
</para>
</sect3>
<sect3 xml:id="migration70.incompatible.foreach.by-ref">
<title>&foreach; by-reference has improved iteration behaviour</title>
<para>
When iterating by-reference, &foreach; will now do a better job of
tracking changes to the array made during iteration. For example,
appending to an array while iterating will now result in the appended
values being iterated over as well:
</para>
<informalexample>
<programlisting role="php">
<![CDATA[
<?php
$array = [0];
foreach ($array as &$val) {
var_dump($val);
$array[1] = 1;
}
?>
]]>
</programlisting>
&example.outputs.5;
<screen>
<![CDATA[
int(0)
]]>
</screen>
&example.outputs.7;
<screen>
<![CDATA[
int(0)
int(1)
]]>
</screen>
</informalexample>
</sect3>
<sect3 xml:id="migration70.incompatible.foreach.object">
<title>Iteration of non-<classname>Traversable</classname> objects</title>
<para>
Iterating over a non-<classname>Traversable</classname> object will now
have the same behaviour as iterating over by-reference arrays. This
results in the
<link linkend="migration70.incompatible.foreach.by-ref">improved behaviour when modifying an array during iteration</link>
also being applied when properties are added to or removed from the
object.
</para>
</sect3>
</sect2>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
indent-tabs-mode:nil
sgml-parent-document:nil
sgml-default-dtd-file:"~/.phpdoc/manual.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
vim600: syn=xml fen fdm=syntax fdl=2 si
vim: et tw=78 syn=sgml
vi: ts=1 sw=1
-->

197
appendices/migration70/incompatible/other.xml Normal file
View file

@ -0,0 +1,197 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- $Revision$ -->
<sect2 xml:id="migration70.incompatible.other">
<title>Other backward incompatible changes</title>
<sect3 xml:id="migration70.incompatible.other.php-tags">
<title>ASP and script PHP tags removed</title>
<para>
Support for using ASP and script tags to delimit PHP code has been removed.
The affected tags are:
</para>
<table>
<title>Removed ASP and script tags</title>
<tgroup cols="2">
<thead>
<row>
<entry>Opening tag</entry>
<entry>Closing tag</entry>
</row>
</thead>
<tbody>
<row>
<entry><code>&lt;%</code></entry>
<entry><code>%&gt;</code></entry>
</row>
<row>
<entry><code>&lt;%=</code></entry>
<entry><code>%&gt;</code></entry>
</row>
<row>
<entry><code>&lt;script language="php"&gt;</code></entry>
<entry><code>&lt;/script&gt;</code></entry>
</row>
</tbody>
</tgroup>
</table>
</sect3>
<sect3 xml:id="migration70.incompatible.func-parameters">
<title>Functions can't have more than one parameter with the same name</title>
<para>
It is no longer possible to define two function parameters with the same name.
For example, the following method will trigger <constant>E_COMPILE_ERROR</constant>:
</para>
<informalexample>
<programlisting role="php">
<![CDATA[
<?php
function foo($a, $b, $unused, $unused) {
//
}
?>
]]>
</programlisting>
</informalexample>
</sect3>
<sect3 xml:id="migration70.incompatible.other.http-raw-post-data">
<title>$HTTP_RAW_POST_DATA removal</title>
<para>
<varname>$HTTP_RAW_POST_DATA</varname> is no longer available. Use the
<literal>php://input</literal> stream instead.
</para>
</sect3>
<sect3 xml:id="migration70.incompatible.other.ini-comments">
<title>Drop #-style comments in INI files</title>
<para>
Support for <literal>#</literal>-style comments in INI files has been dropped. <literal>;</literal>
is the only possible comment indicator now.
</para>
</sect3>
<sect3 xml:id="migration70.incompatible.other.invalid-octals">
<title>Invalid Octal Literals</title>
<para>
Previously, octal literals that contained invalid numbers were silently
truncated (<literal>0128</literal> was taken as <literal>012</literal>).
Now, an invalid octal literal will cause a parse error.
</para>
</sect3>
<sect3 xml:id="migration70.incompatible.other.removed-functions">
<title>Removed functions</title>
<para>
Following functions have been removed from PHP:
</para>
<itemizedlist>
<listitem>
<simpara>
<function>call_user_method</function> and <function>call_user_method_array</function>
</simpara>
</listitem>
<listitem>
<simpara>
<function>mcrypt_generic_end</function> alias in favor of <function>mcrypt_generic_deinit</function>
</simpara>
</listitem>
<listitem>
<simpara>
deprecated <function>mcrypt_ecb</function>,
<function>mcrypt_cbc</function>, <function>mcrypt_cfb</function> and
<function>mcrypt_ofb</function> in favor of <function>mcrypt_decrypt</function>
with an <literal>MCRYPT_MODE_*</literal>
</simpara>
</listitem>
<listitem>
<simpara>
deprecated aliases <function>datefmt_set_timezone_id</function> and
<methodname>IntlDateFormatter::setTimeZoneID</methodname> in favor of
<function>datefmt_set_timezone</function> or <methodname>IntlDateFormatter::setTimeZone</methodname>
</simpara>
</listitem>
<listitem>
<simpara>
<function>set_magic_quotes_runtime</function> and its alias <function>magic_quotes_runtime</function>
</simpara>
</listitem>
<listitem>
<simpara>
<function>set_socket_blocking</function> in favor of its alias <function>stream_set_blocking</function>
</simpara>
</listitem>
<listitem>
<simpara>
<function>dl</function> from fpm-fcgi
</simpara>
</listitem>
<listitem>
<simpara>
<function>imagepsbbox</function>, <function>imagepsencodefont</function>,
<function>imagepsextendedfont</function>, <function>imagepsfreefont</function>,
<function>imagepsloadfont</function>, <function>imagepsslantfont</function>,
<function>imagepstext</function> due to T1Lib support removal
</simpara>
</listitem>
</itemizedlist>
</sect3>
<sect3 xml:id="migration70.incompatible.other.removed-directives">
<title>Removed INI directives</title>
<para>
Following &php.ini; directives have been removed from PHP:
</para>
<itemizedlist>
<listitem>
<simpara>
<link linkend="ini.always-populate-raw-post-data"><parameter>always_populate_raw_post_data</parameter></link>
</simpara>
</listitem>
<listitem>
<simpara>
<link linkend="ini.asp-tags"><parameter>asp_tags</parameter></link>
</simpara>
</listitem>
<listitem>
<simpara>
<parameter>xsl.security_prefs</parameter> - use <methodname>XsltProcessor::setSecurityPrefs</methodname>
instead
</simpara>
</listitem>
</itemizedlist>
</sect3>
</sect2>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
indent-tabs-mode:nil
sgml-parent-document:nil
sgml-default-dtd-file:"~/.phpdoc/manual.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
vim600: syn=xml fen fdm=syntax fdl=2 si
vim: et tw=78 syn=sgml
vi: ts=1 sw=1
-->

325
appendices/migration70/incompatible/variable-handling.xml Normal file
View file

@ -0,0 +1,325 @@
<?xml version="1.0" encoding="utf-8"?>
<!-- $Revision$ -->
<sect2 xml:id="migration70.incompatible.variable-handling">
<title>Changes to variable handling</title>
<para>
PHP 7 now uses an abstract syntax tree when parsing source files. This has
permitted many improvements to the language which were previously
impossible due to limitations in the parser used in earlier versions of
PHP, but has resulted in the removal of a few special cases for consistency
reasons, which has resulted in backward compatibility breaks. These cases
are detailed in this section.
</para>
<sect3 xml:id="migration70.incompatible.variable-handling.indirect">
<title>
Changes to the handling of indirect variables, properties, and methods
</title>
<para>
Indirect access to variables, properties, and methods will now be
evaluated strictly in left-to-right order, as opposed to the previous mix
of special cases. The table below shows how the order of evaluaiton has
changed.
</para>
<para>
<table>
<title>Old and new evaluation of indirect expressions</title>
<tgroup cols="3">
<thead>
<row>
<entry>Expression</entry>
<entry>PHP 5 interpretation</entry>
<entry>PHP 7 interpretation</entry>
</row>
</thead>
<tbody>
<row>
<entry>
<code>$$foo['bar']['baz']</code>
</entry>
<entry>
<code>${$foo['bar']['baz']}</code>
</entry>
<entry>
<code>($$foo)['bar']['baz']</code>
</entry>
</row>
<row>
<entry>
<code>$foo-&gt;$bar['baz']</code>
</entry>
<entry>
<code>$foo-&gt;{$bar['baz']}</code>
</entry>
<entry>
<code>($foo-&gt;$bar)['baz']</code>
</entry>
</row>
<row>
<entry>
<code>$foo-&gt;$bar['baz']()</code>
</entry>
<entry>
<code>$foo-&gt;{$bar['baz']}()</code>
</entry>
<entry>
<code>($foo-&gt;$bar)['baz']()</code>
</entry>
</row>
<row>
<entry>
<code>Foo::$bar['baz']()</code>
</entry>
<entry>
<code>Foo::{$bar['baz']}()</code>
</entry>
<entry>
<code>(Foo::$bar)['baz']()</code>
</entry>
</row>
</tbody>
</tgroup>
</table>
</para>
<para>
Code that used the old right-to-left evaluation order must be rewritten to
explicitly use that evaluation order with curly braces (see the above
middle column). This will make the code both forwards compatible with PHP
7.x and backwards compatible with PHP 5.x.
</para>
</sect3>
<sect3 xml:id="migration70.incompatible.variable-handling.list">
<title>Changes to <function>list</function> handling</title>
<sect4 xml:id="migration70.incompatible.variable-handling.list.order">
<title>
<function>list</function> no longer assigns variables in reverse order
</title>
<para>
<function>list</function> will now assign values to variables in the
order they are defined, rather than reverse order. In general, this only
affects the case where <function>list</function> is being used in
conjunction with the array <code>[]</code> operator, as shown below:
</para>
<informalexample>
<programlisting role="php">
<![CDATA[
<?php
list($a[], $a[], $a[]) = [1, 2, 3];
var_dump($a);
?>
]]>
</programlisting>
&example.outputs.5;
<screen>
<![CDATA[
array(3) {
[0]=>
int(3)
[1]=>
int(2)
[2]=>
int(1)
}
]]>
</screen>
&example.outputs.7;
<screen>
<![CDATA[
array(3) {
[0]=>
int(1)
[1]=>
int(2)
[2]=>
int(3)
}
]]>
</screen>
</informalexample>
<para>
In general, it is recommended not to rely on the order in which
<function>list</function> assignments occur, as this is an implementation
detail that may change again in the future.
</para>
</sect4>
<sect4 xml:id="migration70.incompatible.variable-handling.list.empty">
<title>Empty <function>list</function> assignments have been removed</title>
<para>
<function>list</function> constructs can no longer be empty, or contain
empty variables. The following are no longer allowed:
</para>
<informalexample>
<programlisting role="php">
<![CDATA[
<?php
list() = $a;
list(,,) = $a;
list($x, list(), $y) = $a;
?>
]]>
</programlisting>
</informalexample>
</sect4>
<sect4 xml:id="migration70.incompatible.variable-handling.list.string">
<title><function>list</function> cannot unpack <type>string</type>s</title>
<para>
<function>list</function> can no longer unpack <type>string</type>
variables. <function>str_split</function> should be used instead.
</para>
</sect4>
</sect3>
<sect3 xml:id="migration70.incompatible.variable-handling.array-order">
<title>
Array ordering when elements are automatically created during by reference
assignments has changed
</title>
<para>
The order of the elements in an array has changed when those elements have
been automatically created by referencing them in a by reference
assignment. For example:
</para>
<informalexample>
<programlisting role="php">
<![CDATA[
<?php
$array = [];
$array["a"] =& $array["b"];
$array["b"] = 1;
var_dump($array);
?>
]]>
</programlisting>
&example.outputs.5;
<screen>
<![CDATA[
array(2) {
["b"]=>
&int(1)
["a"]=>
&int(1)
}
]]>
</screen>
&example.outputs.7;
<screen>
<![CDATA[
array(2) {
["a"]=>
&int(1)
["b"]=>
&int(1)
}
]]>
</screen>
</informalexample>
</sect3>
<sect3 xml:id="migration70.incompatible.variable-handling.global">
<title>&global; only accepts simple variables</title>
<para>
<link linkend="language.variables.variable">Variable variables</link> can
no longer be used with the &global; keyword. The curly brace syntax can be
used to emulate the previous behaviour if required:
</para>
<informalexample>
<programlisting role="php">
<![CDATA[
<?php
function f() {
// Valid in PHP 5 only.
global $$foo->bar;
// Valid in PHP 5 and 7.
global ${$foo->bar};
}
?>
]]>
</programlisting>
</informalexample>
<para>
As a general principle, using anything other than a bare variable with
&global; is discouraged.
</para>
</sect3>
<sect3 xml:id="migration70.incompatible.variable-handling.parentheses">
<title>
Parentheses around function parameters no longer affect behaviour
</title>
<para>
In PHP 5, using redundant parentheses around a function parameter could
quiet strict standards warnings when the function parameter was passed by
reference. The warning will now always be issued.
</para>
<informalexample>
<programlisting role="php">
<![CDATA[
<?php
function getArray() {
return [1, 2, 3];
}
function squareArray(array &$a) {
foreach ($a as &$v) {
$v **= 2;
}
}
// Generates a warning in PHP 7.
squareArray((getArray()));
?>
]]>
</programlisting>
&example.outputs;
<screen>
<![CDATA[
Notice: Only variables should be passed by reference in /tmp/test.php on line 13
]]>
</screen>
</informalexample>
</sect3>
</sect2>
<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
indent-tabs-mode:nil
sgml-parent-document:nil
sgml-default-dtd-file:"~/.phpdoc/manual.ced"
sgml-exposed-tags:nil
sgml-local-catalogs:nil
sgml-local-ecat-files:nil
End:
vim600: syn=xml fen fdm=syntax fdl=2 si
vim: et tw=78 syn=sgml
vi: ts=1 sw=1
-->