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

Correcting some typos.

Browse source 
git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@40028 c90b9560-bf6c-de11-be94-00142212c4b1
This commit is contained in:
Damien Seguy 2001-01-23 10:29:05 +00:00
parent 0436090b09
commit c6504e711d
1 changed files with 16 additions and 16 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

32
appendices/migration4.xml
View file

@ -73,21 +73,21 @@
<para>
Error reporting level should now be configured by explicitly
taking away the warning levels you do not want to generate error
messages by x-oring them from the symbolic constant E_ALL. Sounds
complicated? Well, lets say you want the error reporting system
to report all but the simple style warnings that are categorized
by the symbolic constant E_NOTICE. Then you'll put the following
into your <filename>php.ini</filename>:
<literal>error_reporting = E_ALL & ~ ( E_NOTICE )</literal>.
If you wan't to suppress warnings too you add up the appropriate
messages by x-oring them from the symbolic constant
<literal>E_ALL</literal>. Sounds complicated? Well, lets say you want
the error reporting system to report all but the simple style warnings
that are categorized by the symbolic constant <literal>E_NOTICE</literal>.
Then you'll put the following into your <filename>php.ini</filename>:
<literal>error_reporting = E_ALL & ~ ( E_NOTICE )</literal>.
If you want to suppress warnings too you add up the appropriate
constant within the braces using the binary or operator '|':
<literal>error_reporting= E_ALL & ~ ( E_NOTICE | E_WARNING )</literal>.
<literal>error_reporting= E_ALL & ~ ( E_NOTICE | E_WARNING )</literal>.
</para>
<warning>
<para>
Using the old values 7 and 15 for setting up error reporting is a
very bad idea as this suppresses some of the newly added error
classes including parese errors. This may leed to very strange
classes including parese errors. This may lead to very strange
behavior as scripts might no longer work without error messages
showing up anywhere.
</para>
@ -197,7 +197,7 @@
<para>
As PHP 4.0 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 al already happend by
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
appropriate values in the <filename>php.ini</filename> file.
@ -236,7 +236,7 @@
<para>
Another more practical change is that it is no longer possible to
call <function>unset</function> indirectly, that is
<literal>$func="unset"; $func($somevar)</literal> won't work anymore.
<literal>$func="unset"; $func($somevar)</literal> won't work anymore.
</para>
</section>
</section>
@ -247,7 +247,7 @@
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 origibal sources. A detailed description of the actual
the original sources. A detailed description of the actual
porting process is not part of this text (yet).
</para>
</section>
@ -262,17 +262,17 @@
<para>
To do so you have to enclose your variables with curly braces
with the dollar sign immediately following the opening brace:
<literal>{$...}</literal>
<literal>{$...}</literal>
</para>
<para>
To embed the value of an object member variable into a string you
simply write <literal>"text {$obj->member} text"</literal> while
simply write <literal>"text {$obj->member} text"</literal> while
in PHP 3.0 you had to use something like <literal>"text
".$obj->member." text"</literal>.
</para>
<para>
This should lead to more readable code, while it may break existing
scripts written for PHP 3.0. But ou can easily check for this kind of
scripts written for PHP 3.0. 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 tool.
@ -283,7 +283,7 @@
<section>
<title>Cookies</title>
<para>
PHP 3.0 hat the bad habbit of setting cookies in the reverse order
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
breaks with this habbit and creates the cookie header lines in
exactly the same order as you set the cookies in the code.