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

s/([34]).0/$1/, mostly. this section could really use a polish.

Browse source 
git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@65473 c90b9560-bf6c-de11-be94-00142212c4b1
This commit is contained in:
jim winstead 2001-12-17 19:27:31 +00:00
parent c9b0eb3bb8
commit 00a72bb55f
1 changed files with 46 additions and 50 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

96
appendices/migration4.xml
View file

@ -1,16 +1,16 @@
<?xml version="1.0" encoding="iso-8859-1"?>
<!-- $Revision: 1.16 $ -->
<!-- $Revision: 1.17 $ -->
<appendix id="migration4">
<title>Migrating from PHP 3.0 to PHP 4.0</title>
<title>Migrating from PHP 3 to PHP 4</title>
<section id='migration4.changes'>
<title>What has changed in PHP 4.0</title>
<title>What has changed in PHP 4</title>
<para>
PHP 4.0 and the integrated Zend engine have greatly inproved PHPs
PHP 4 and the integrated Zend engine have greatly inproved PHPs
performance and capabilities, but great care has been taken to
break as little existing code as possible. So migrating your code
from PHP 3.0 to 4.0 should be much easier than migrating from
PHP/FI 2.0 to PHP 3.0. A lot of existing PHP 3.0 code should be
from PHP 3 to 4 should be much easier than migrating from
PHP/FI 2 to PHP 3. A lot of existing PHP 3 code should be
ready to run without changes, but you should still know about the
few differences and take care to test your code before switching
versions in production environments. The following should give you
@ -112,7 +112,7 @@ php_admin_flag [PHP directive name] [On|Off]
<listitem><simpara>Standard values (or flags) cannot control certain PHP directives, for example - safe mode (if you could override safe mode settings in .htaccess files, it would defeat safe-mode's purpose). In contrast, Admin values can modify the value of any PHP directive.</simpara></listitem>
</itemizedlist>
<simpara>
To make the transition process easier, PHP 4.0 is bundled with scripts that automatically convert your Apache configuration and .htaccess files to work with both PHP 3.0 and PHP 4.0. These scripts do NOT convert the mime type lines! You have to convert these yourself.
To make the transition process easier, PHP 4 is bundled with scripts that automatically convert your Apache configuration and .htaccess files to work with both PHP 3 and PHP 4. These scripts do NOT convert the mime type lines! You have to convert these yourself.
</simpara>
<para>
To convert your Apache configuration files, run the apconf-conv.sh script (available in the scripts/apache/ directory). For example:
@ -177,7 +177,7 @@ php_admin_flag [PHP directive name] [On|Off]
considered as very bad style anyway.
</para>
<para>
Another thing no longer possible, though rarely seen in PHP 3.0
Another thing no longer possible, though rarely seen in PHP 3
code is returning values from a required file. Returning a value
from an included file is still possible.
</para>
@ -189,17 +189,16 @@ php_admin_flag [PHP directive name] [On|Off]
<section id='migration4.error-reporting.config'>
<title>Configuration changes</title>
<para>
With PHP 3.0 the error reporting level was set as a simple
With PHP 3 the error reporting level was set as a simple
numeric value formed by summing up the numbers related to
different error levels. Usual values where 15 for reporting all
errors and warnings or 7 for reporting everything but simple
notice messages reporting bad style and things like that.
</para>
<para>
PHP 4.0 now has a greater set of different error and warning
levels and comes with a configuration parser that now allows for
symbolic constants to be used for setting up the intended
behavior.
PHP 4 has a larger set of error and warning levels and comes with a
configuration parser that now allows for symbolic constants to be used
for setting the intended behavior.
</para>
<para>
Error reporting level should now be configured by explicitly
@ -243,24 +242,24 @@ php_admin_flag [PHP directive name] [On|Off]
<section id='migration4.error-reporting.additions'>
<title>Additional warning messages</title>
<para>
A lot of existing PHP 3.0 code uses language constructs that
A lot of existing PHP 3 code uses language constructs that
should be considered as very bad style as this code, while doing
the intended thing now, could easily be broken by changes in
other places. PHP 4.0 will output a lot of notice messages in
such situations where PHP 3.0 didn't. The easy fix is to just
other places. PHP 4 will output a lot of notice messages in
such situations where PHP 3 didn't. The easy fix is to just
turn off E_NOTICE messages, but it is usually a good idea to fix
the code instead.
</para>
<para>
The most common case that will now produce notice messages is the
use of unquoted string constants as array indices. Both PHP 3.0
and 4.0 will fall back to interprete theese as strings if no
use of unquoted string constants as array indices. Both PHP 3
and 4 will fall back to interprete theese as strings if no
keyword or constant is known by that name, but whenever a
constant by that name had been defined anywhere else in the code
it might break your script. This can even become a security risk
if some intruder manages to redefine string constants in a way
that makes your script give him access rights he wasn't intended
to have. So PHP 4.0 will now warn you whenever you use unquoted
to have. So PHP 4 will now warn you whenever you use unquoted
string constants as for example in
<literal>$HTTP_SERVER_VARS[REQUEST_METHOD]</literal>. Changing it
to <literal>$HTTP_SERVER_VARS['REQUEST_METHOD']</literal> will
@ -268,7 +267,7 @@ php_admin_flag [PHP directive name] [On|Off]
of your code.
</para>
<para>
Another thing PHP 4.0 will now tell you about is the use of
Another thing PHP 4 will now tell you about is the use of
uninitialized variables or array elements.
</para>
</section>
@ -279,7 +278,7 @@ php_admin_flag [PHP directive name] [On|Off]
<title>Initializers</title>
<para>
Static variable and class member initializers only accept scalar
values while in PHP 3.0 they accepted any valid expression. This
values while in PHP 3 they accepted any valid expression. This
is, once again, due to the split between parsing and execution as
no code has yet been executed when the parser sees the
initializer.
@ -297,7 +296,7 @@ php_admin_flag [PHP directive name] [On|Off]
The perhaps most cotroversal change in behavior has happend to the
behavior of the <function>empty</function>. A String containing
only the character '0' (zero) is now considered empty while it
wasn't in PHP 3.0.
wasn't in PHP 3.
</para>
<para>
This new behavior makes sense in web applications, with all input
@ -312,11 +311,11 @@ php_admin_flag [PHP directive name] [On|Off]
<section id='migration4.missing'>
<title>Missing functions</title>
<para>
While PHP 4.0 comes with a lot of new features, functions and
extensions, you may still find some functions from version 3.0
While PHP 4 comes with a lot of new features, functions and
extensions, you may still find some functions from version 3
missing. A small number of core functions has vanished because
they do not work with the new scheme of splitting parsing and
execution as introduced into 4.0 with the Zend engine. Other
execution as introduced into 4 with the Zend engine. Other
functions and even complete extensions have become obsolete as
newer functions and extensions serve the same task better and/or
in a more general way. Some functions just simply haven't been
@ -327,18 +326,17 @@ php_admin_flag [PHP directive name] [On|Off]
<section id='migration4.missing.concept'>
<title>Functions missing due to conceptual changes</title>
<para>
As PHP 4.0 now seperates parsing from execution it is no longer
As PHP 4 now seperates parsing from execution it is no longer
possible to change the behavior of the parser (now embedded in
the Zend engine) at runtime as parsing already happend by
then. So the function <function>short_tags</function> has ceased
to exist. You can still change the parsers behavior by setting
then. So the function <function>short_tags</function> no longer
exists. You can still change the parsers behavior by setting
appropriate values in the <filename>php.ini</filename> file.
</para>
<para>
Another feature from PHP 3.0 that didn't make it into 4.0 is the
experimental debugging interface as described in ??? in this
manual. A seperate &true; debuger is promissed to be released as a
Zend product but hasn't become visible yet.
Another feature of PHP 3 that is not a part of PHP 4 is the bundled
debugging interface. There are third-party add-ons for the Zend engine
which add similar functionality.
</para>
</section>
@ -354,15 +352,14 @@ php_admin_flag [PHP directive name] [On|Off]
<title>Changed status for <function>unset</function></title>
<para>
<function>unset</function>, although still available, is
implemented a literal different in PHP 4.0 so that it no longer
counts as a 'real' function.
implemented as a language construct rather than a function.
</para>
<para>
This has no direct consequences as the behavior of
<function>unset</function> didn't change, but testing for "unset"
usign <function>function_exists</function> will return
&false; as it would with othern lowlevel
functions like <function>echo</function>.
This does not have any consequences on the behavior of
<function>unset</function>, but testing for "unset" using
<function>function_exists</function> will return &false; as it would with
other language constructs that look like functions such as
<function>echo</function>.
</para>
<para>
Another more practical change is that it is no longer possible to
@ -374,20 +371,19 @@ php_admin_flag [PHP directive name] [On|Off]
</section>
<section id='migration4.extensions'>
<title>PHP 3.0 extension</title>
<title>PHP 3 extension</title>
<para>
Extensions written for PHP 3.0 will not work with PHP 4.0 anymore,
neither as binaries nor at the source level. It is not to
difficult to port your extensions to PHP 4.0 if you have access to
the original sources. A detailed description of the actual porting
process is not part of this text (yet).
Extensions written for PHP 3 will not work with PHP 4, neither as binaries
nor at the source level. It is not difficult to port extensions to PHP 4
if you have access to the original source. A detailed description of the
actual porting process is not part of this text.
</para>
</section>
<section id='migration4.strings'>
<title>Variable substitution in strings</title>
<para>
PHP 4.0 adds a new mechanism to variable substitution in
PHP 4 adds a new mechanism to variable substitution in
strings. You can now finally access object member variables and
elements from multidimensional arrays within strings.
</para>
@ -399,12 +395,12 @@ php_admin_flag [PHP directive name] [On|Off]
<para>
To embed the value of an object member variable into a string you
simply write <literal>"text {$obj-&gt;member} text"</literal> while
in PHP 3.0 you had to use something like <literal>"text
in PHP 3 you had to use something like <literal>"text
".$obj-&gt;member." text"</literal>.
</para>
<para>
This should lead to more readable code, while it may break
existing scripts written for PHP 3.0. But you can easily check for
existing scripts written for PHP 3. But you can easily check for
this kind of problem by checking for the character combination
<literal>{$</literal> in your code and by replacing it with
<literal>\{$</literal> with your favourite search-and-replace
@ -415,8 +411,8 @@ php_admin_flag [PHP directive name] [On|Off]
<section id='migration4.cookies'>
<title>Cookies</title>
<para>
PHP 3.0 hat the bad habit of setting cookies in the reverse order
of the <function>setcookie</function> calls in your code. PHP 4.0
PHP 3 had the bad habit of setting cookies in the reverse order
of the <function>setcookie</function> calls in your code. PHP 4
breaks with this habbit and creates the cookie header lines in
exactly the same order as you set the cookies in the code.
</para>