i'm right?

git-svn-id: https://svn.php.net/repository/phpdoc/en/trunk@105021 c90b9560-bf6c-de11-be94-00142212c4b1
This commit is contained in:
Thomas Gonzalez Miranda 2002-11-20 12:19:11 +00:00
parent 804296c609
commit cffa746463
7 changed files with 752 additions and 734 deletions

View file

@ -1,95 +1,94 @@
<?xml version="1.0" encoding="iso-8859-1"?>
<!-- $Revision: 1.19 $ -->
<!-- $Revision: 1.20 $ -->
<appendix id="migration">
<title>Migrating from PHP/FI 2 to PHP 3</title>
<title>Mirgrando do PHP/FI para o PHP 3</title>
<section id="migration.about">
<title>About the incompatibilities in 3.0</title>
<title>Sobre as incompatibilidades do 3.0</title>
<simpara>
PHP 3.0 is rewritten from the ground up. It has a proper parser
that is much more robust and consistent than 2.0's. 3.0 is also
significantly faster, and uses less memory. However, some of
these improvements have not been possible without compatibility
changes, both in syntax and functionality.
PHP 3.0 foi totalmente reescrito. Ele tem um parser apropriado
que &eacute; muito mais robusto e consistente que o da vers&atilde;o 2.0. 3.0
&eacute; tamb&eacute;m significamente mais r&aacute;pido, e usa menos mem&oacute;ria. Entretanto
algumas dessas melhorias n&atilde;o seriam poss&iacute;veis sem mudan&ccedil;as na compatibilidade,
na sintaxe e na funcionalidade.
</simpara>
<simpara>
In addition, PHP's developers have tried to clean up both PHP's
syntax and semantics in version 3.0, and this has also caused some
incompatibilities. In the long run, we believe that these changes
are for the better.
Al&eacute;m do mais, os desenvolvedores do PHP tentaram limpar ambas
sintaxe e sem&acirc;nticas da vers&atilde;o 3.0 do PHP, e isto tamb&eacute;m traz algumas
incompatbilidades. A longo prazo, n&oacute;s acreditamos que estas mudan&ccedil;as
s&atilde;o para melhor.
</simpara>
<simpara>
This chapter will try to guide you through the incompatibilities
you might run into when going from PHP/FI 2.0 to PHP 3.0 and help
you resolve them. New features are not mentioned here unless
necessary.
Este cap&iacute;tulo tentar&aacute; guiar voc&ecirc; com as incompatibilidades que voc&ecirc;
encontrar&aacute; quando estiver migrando do PHP/FI 2.0 para o PHP 3.0 e
ajudar&aacute; a resolver elas. Novas caracter&iacute;sticas n&atilde;o s&atilde;o mencionadas aqui
a menos que seja necess&aacute;rio.
</simpara>
<simpara>
A conversion program that can automatically convert your old
PHP/FI 2.0 scripts exists. It can be found in the
<filename class="directory">convertor</filename> subdirectory of the PHP 3.0
distribution. This program only catches the syntax changes though,
so you should read this chapter carefully anyway.
Um programa que converte automaticamente seus scripts em PHP/FI 2.0 existe.
Ele pode ser encontrado no subdiret&oacute;rio <filename class="directory">convertor</filename>
da distribui&ccedil;&atilde;o do PHP 3.0. Este programa apenas capta altera&ccedil;&otilde;es de sintaxe,
portanto voc&ecirc; deve ler atentamente este cap&iacute;tulo.
</simpara>
</section>
<section id="migration.startendtags">
<title>Start/end tags</title>
<title>Tags de Come&ccedil;o/fim</title>
<para>
The first thing you probably will notice is that PHP's start and end
tags have changed. The old <literal>&lt;? &gt;</literal> form has been
replaced by three new possible forms:
A primeira coisa que voc&ecirc; provavelmente ir&aacute; reparar &eacute; que as tags de
come&ccedil;o e fim do PHP mudaram. O velho foi <literal>&lt;? &gt;</literal>
modificado para tr&ecirc;s formas poss&iacute;veis:
<example>
<title>Migration: old start/end tags</title>
<title>Migrando: da velha tag come&ccedil;o/fim</title>
<programlisting role="php">
<![CDATA[
<? echo "This is PHP/FI 2.0 code.\n"; ?>
<? echo "Este &eacute; um c&oacute;digo em PHP/FI 2.0.\n"; >
]]>
</programlisting>
</example>
As of version 2.0, PHP/FI also supports this variation:
Como na vers&atilde;o 2.0, PHP/FI tamb&eacute;m suporta esta varia&ccedil;&atilde;o:
<example>
<title>Migration: first new start/end tags</title>
<title>Migrando: primeira forma das tags come&ccedil;o/fim</title>
<programlisting role="php">
<![CDATA[
<? echo "This is PHP 3.0 code!\n"; ?>
<? echo "Este &eacute; um c&oacute;digo em PHP 3.0!\n"; ?>
]]>
</programlisting>
</example>
Notice that the end tag now consists of a question mark and a
greater-than character instead of just greater-than. However, if
you plan on using XML on your server, you will get problems with
the first new variant, because PHP may try to execute the XML
markup in XML documents as PHP code. Because of this, the
following variation was introduced:
Repare que a tag de fechamento agora consiste em um sinal de interroga&ccedil;&atilde;o e uma
tag de fechamento e n&atilde;o apenas em uma tag de fechamento. Entretanto, se
voc&ecirc; planeja usar XML no seu servidor, voc&ecirc; obeter&aacute; alguns problemas com a
nova varia&ccedil;&atilde;o, porque o PHP pode tentar executar as tags de marca&ccedil;&atilde;o dos
documentos em XML como c&oacute;digos PHP. Por causa disto, a seguinte modifica&ccedil;&atilde;o
foi adicionada:
<example>
<title>Migration: second new start/end tags</title>
<title>Migrando: segunda forma das tags come&ccedil;o/fim</title>
<programlisting role="php">
<![CDATA[
<?php echo "This is PHP 3.0 code!\n"; ?>
<?php echo "Este &eacute; um c&oacute;digo em PHP 3.0!\n"; ?>
]]>
</programlisting>
</example>
Some people have had problems with editors that don't understand
the processing instruction tags at all. Microsoft FrontPage is one
such editor, and as a workaround for these, the following variation
was introduced as well:
Algumas pessoas obtiveram problemas com editores que n&atilde;o entendem
todas as tags de processamento. O Microsoft Frontpage &eacute; um destes editores,
e pensando nestes editores, foi adicionado mais uma modifica&ccedil;&atilde;o que &eacute; mostrada
abaixo:
<example>
<title>Migration: third new start/end tags</title>
<title>Migrando: terceira forma das tags come&ccedil;o/fim</title>
<programlisting role="php">
<![CDATA[
<script language="php">
echo "This is PHP 3.0 code!\n";
echo "Este &eacute; um c&oacute;digo em PHP 3.0!\n";
</script>
]]>
@ -99,67 +98,66 @@
</section>
<section id="migration.if-endif">
<title>if..endif syntax</title>
<title>sintaxe if..endif</title>
<para>
The `alternative' way to write if/elseif/else statements, using if();
elseif(); else; endif; cannot be efficiently implemented without
adding a large amount of complexity to the 3.0 parser. Because of
this, the syntax has been changed:
A maneira 'alternativa' de escrever as instru&ccedil;&otilde;es if/elseif/else , usando if();
elseif(); else; endif; n&atilde;o puderam ser eficientemente implementadas sem adicionar
uma quantidade grande de complexidade ao parser 3.0. Por causa disso, a sintaxe foi
alterada para:
<example>
<title>Migration: old if..endif syntax</title>
<title>Migrando: velha sintaxe if..endif</title>
<programlisting role="php">
<![CDATA[
if ($foo);
echo "yep\n";
echo "sim\n";
elseif ($bar);
echo "almost\n";
echo "quase\n";
else;
echo "nope\n";
echo "n&atilde;o\n";
endif;
]]>
</programlisting>
</example>
<example>
<title>Migration: new if..endif syntax</title>
<title>Migrando: nova sintaxe if..endif</title>
<programlisting role="php">
<![CDATA[
if ($foo):
echo "yep\n";
echo "sim\n";
elseif ($bar):
echo "almost\n";
echo "quase\n";
else:
echo "nope\n";
echo "n&atilde;o\n";
endif;
]]>
</programlisting>
</example>
Notice that the semicolons have been replaced by colons in all
statements but the one terminating the expression (endif).
Repare que todos os pontos-e-v&iacute;rgulas foram trocados por dois-pontos em todas
as instru&ccedil;&otilde;es, exceto na instru&ccedil;&atilde;o de fechamento (endif).
</para>
</section>
<section id="migration-while">
<title>while syntax</title>
<title>sintaxe while</title>
<para>
Just like with if..endif, the syntax of while..endwhile has changed
as well:
Assim como o if...endif, a sintaxe do while...endwhile foi alterada:
<example>
<title>Migration: old while..endwhile syntax</title>
<title>Migrando: a velha sintaxe do while..endwhile</title>
<programlisting role="php">
<![CDATA[
while ($more_to_come);
while ($mais_a_vir);
...
endwhile;
]]>
</programlisting>
</example>
<example>
<title>Migration: new while..endwhile syntax</title>
<title>Migrando: nova sintaxe do while..endwhile</title>
<programlisting role="php">
<![CDATA[
while ($more_to_come):
while ($mais_a_vir):
...
endwhile;
]]>
@ -168,22 +166,22 @@ endwhile;
</para>
<warning>
<simpara>
If you use the old while..endwhile syntax in PHP 3.0,
you will get a never-ending loop.
Se voc&ecirc; usar a velha sintaxe do while...endwhile no PHP 3.0,
voc&ecirc; ir&aacute; obter um loop que nunca-termina.
</simpara>
</warning>
</section>
<section id="migration.expr">
<title>Expression types</title>
<title>Tipos de Express&otilde;es</title>
<simpara>
PHP/FI 2.0 used the left side of expressions to determine what type
the result should be. PHP 3.0 takes both sides into account when
determining result types, and this may cause 2.0 scripts to behave
unexpectedly in 3.0.
O PHP/FI 2.0 usa o lado esquerdo das express&otilde;es para determinar qual o tipo
de resultado que deve retornar. O PHP 3.0 examina ambos os lados quando
determina os tipos de resultados, e isto pode fazer com que scripts da vers&atilde;o
2.0 comportem-se inesperadamente.
</simpara>
<para>
Consider this example:
Considere este exemplo:
<informalexample>
<programlisting role="php">
<![CDATA[
@ -199,20 +197,17 @@ while ("" != $key) {
</programlisting>
</informalexample>
In PHP/FI 2.0, this would display both of $a's indices. In PHP
3.0, it wouldn't display anything. The reason is that in PHP 2.0,
because the left argument's type was string, a string comparison
was made, and indeed <literal>""</literal> does not equal
<literal>"0"</literal>, and the loop went through. In PHP 3.0,
when a string is compared with an integer, an integer comparison is
made (the string is converted to an integer). This results in
comparing <literal>atoi("")</literal> which is
<literal>0</literal>, and <literal>variablelist</literal> which is
also <literal>0</literal>, and since <literal>0==0</literal>, the
loop doesn't go through even once.
No PHP/FI 2.0, isto mostraria ambos os &iacute;ndices de $a. No PHP 3.0,
isto n&atilde;o mostraria nada. A raz&atilde;o &eacute; que no PHP 2.0, &eacute; porque os argumentos
da esquerda eram do tipo string, ent&atilde;o uma compara&ccedil;&atilde;o de string foi feita,
e certamente <literal>""</literal> n&atilde;o &eacute; igual &agrave; <literal>"0"</literal>, e o
la&ccedil;o &eacute; completado. No PHP 3.0, quando uma string &eacute; comparada com um inteiro, uma
compara&ccedil;&atilde;o de inteiro &eacute; feita (a string &eacute; convertida para inteiro). Isto resultado em uma
compara&ccedil;&atilde;o em que <literal>atoi("")</literal> &eacute; <literal>0</literal>, e <literal>variablelist</literal>
tamb&eacute;m &eacute; <literal>0</literal>, deste que <literal>0==0</literal>, o loop n&atilde;o executa mais de uma vez.
</para>
<para>
The fix for this is simple. Replace the while statement with:
A corre&ccedil;&atilde;o para iso &eacute; simples. Troque aquele while por:
<informalexample>
<programlisting role="php">
<![CDATA[
@ -224,60 +219,57 @@ while ((string)$key != "") {
</section>
<section id="migration.errors">
<title>Error messages have changed</title>
<title>Mensagens de erro foram alteradas</title>
<simpara>
PHP 3.0's error messages are usually more accurate than 2.0's were,
but you no longer get to see the code fragment causing the error.
You will be supplied with a file name and a line number for the
error, though.
No PHP 3.0 as mensagens de erro geralmente s&atilde;o mais exatadas do que as do PHP 2.0,
mas voc&ecirc; n&atilde;o ver&aacute; mais o fragmento de c&oacute;digo que cont&eacute;m o erro. Voc&ecirc; ser&aacute; notificado
com o nome do arquivo e o n&uacute;mero da linha onde ocorreu o erro.
</simpara>
</section>
<section id="migration.booleval">
<title>Short-circuited boolean evaluation</title>
<simpara>
In PHP 3.0 boolean evaluation is short-circuited. This means that
in an expression like <literal>(1 || test_me())</literal>, the
function <function>test_me</function> would not be executed since
nothing can change the result of the expression after the
<literal>1</literal>.
No PHP 3.0 a avalia&ccedil;&atilde;o booleana &eacute; short-circuited. Isto significa que
uma express&atilde;o como esta <literal>(1 || teste_me())</literal>, da fun&ccedil;&atilde;o
<function>teste_me</function> n&atilde;o seria executada porque nada pode mudar
o resultado da express&atilde;o ap&oacute;s <literal>1</literal>.
</simpara>
<simpara>
This is a minor compatibility issue, but may cause unexpected
side-effects.
Esta &eacute; uma pequena incompatibilidade, mas poder&aacute; causar side-effects
inesperados.
</simpara>
</section>
<section id="migration.truefalse">
<title>Function &true;/&false; return values</title>
<title>Fun&ccedil;&otilde;es &true;/&false; retornam valores</title>
<simpara>
Most internal functions have been rewritten so they return &true;
when successful and &false; when failing, as opposed to 0 and -1 in
PHP/FI 2.0, respectively. The new behaviour allows for more
logical code, like <literal>$fp = fopen("/your/file") or
fail("darn!");</literal>. Because PHP/FI 2.0 had no clear rules
for what functions should return when they failed, most such
scripts will probably have to be checked manually after using the
2.0 to 3.0 convertor.
A maioria das fun&ccedil;&otilde;es foram reescritas sendo assim, retornam &true;
quando obt&eacute;m sucesso e &false; quando falham, ao contr&aacute;rio de 0 e -1 no
PHP/FI 2.0, respectivamente. O novo comportamento permite um c&oacute;digo mais
l&oacute;gico, como <literal>$fp = fopen("/seu/arquivo") or fail("merda!");</literal>.
Porque o PHP/FI 2.0 n&atilde;o tem regras claras quanto ao que a fun&ccedil;&atilde;o dever&aacute; retornar
caso falhe, muitos scripts provavelmente dever&atilde;o ser checados manualmente ap&oacute;s usar
o conversor de 2.0 para 3.0.
</simpara>
<para>
<example>
<title>Migration from 2.0: return values, old code</title>
<title>Migrando do 2.0: retornando valores, c&oacute;digo antigo</title>
<programlisting role="php">
<![CDATA[
$fp = fopen($file, "r");
$fp = fopen($arquivo, "r");
if ($fp == -1);
echo("Could not open $file for reading<br>\n");
echo("N&atilde;o foi poss&iacute;vel abrir $arquivo para leitura<br>\n");
endif;
]]>
</programlisting>
</example>
<example>
<title>Migration from 2.0: return values, new code</title>
<title>Migrando do 2.0: retornando valores, novo c&oacute;digo</title>
<programlisting role="php">
<![CDATA[
$fp = @fopen($file, "r") or print("Could not open $file for reading<br>\n");
$fp = @fopen($arquivo, "r") or print("N&atilde;o foi poss&iacute;vel abrir $arquivo para leitura<br>\n");
]]>
</programlisting>
</example>
@ -285,65 +277,60 @@ $fp = @fopen($file, "r") or print("Could not open $file for reading<br>\n");
</section>
<section id="migration-other">
<title>Other incompatibilities</title>
<title>Outras incompatibilidades</title>
<itemizedlist>
<listitem><simpara>
The PHP 3.0 Apache module no longer supports Apache versions
prior to 1.2. Apache 1.2 or later is required.
O m&oacute;dulo do PHP 3.0 para o Apache n&atilde;o suporta vers&otilde;es anteriores &agrave; 1.2.
Apache 1.2 ou atual &eacute; requerido.
</simpara></listitem>
<listitem><simpara>
<function>echo</function> no longer supports a format string.
Use the <function>printf</function> function instead.
<function>echo</function> n&atilde;o suporta mais strings formatadas.
Use a fun&ccedil;&atilde;o <function>printf</function> para isto.
</simpara></listitem>
<listitem><simpara>
In PHP/FI 2.0, an implementation side-effect caused
<literal>$foo[0]</literal> to have the same effect as
<literal>$foo</literal>. This is not true for PHP 3.0.
No PHP/FI 2.0, uma execu&ccedil;&atilde;o "side-effect" faz com que <literal>$foo[0]</literal>
tenha o mesmo efeito que <literal>$foo</literal>. No PHP 3.0 isto n&atilde;o &eacute; verdadeiro.
</simpara></listitem>
<listitem>
<simpara>
Reading arrays with <literal>$array[]</literal> is no longer
supported
Ler arrays com <literal>$array[]</literal> n&atilde;o &eacute; mais
suportado
</simpara>
<simpara>
That is, you cannot traverse an array by having a loop that does
<literal>$data = $array[]</literal>. Use <function>current</function>
and <function>next</function> instead.
Isto &eacute;, voc&ecirc; n&atilde;o pode atravessar um array fazendo um loop que cont&eacute;m <literal>$data = $array[]</literal>.
Ao inv&eacute;s disso use <function>current</function> e <function>next</function>.
</simpara>
<simpara>
Also, <literal>$array1[] = $array2</literal> does not
append the values of <literal>$array2</literal> to
<literal>$array1</literal>, but appends
<literal>$array2</literal> as the last entry of
<literal>$array1</literal>. See also multidimensional array
support.
Tamb&eacute;m, <literal>$array1[] = $array2</literal> n&atilde;o adiciona
valores de <literal>$array2</literal> &agrave; <literal>$array1</literal>,
mas adiciona <literal>$array2</literal> como a &uacute;ltima entrada de
<literal>$array1</literal>. Veja tamb&eacute;m o suporte ao array multidimensional.
</simpara>
</listitem>
<listitem>
<simpara>
<literal>"+"</literal> is no longer overloaded as a
concatenation operator for strings, instead it converts it's
arguments to numbers and performs numeric addition. Use
<literal>"."</literal> instead.
<literal>"+"</literal> n&atilde;o &eacute; mais considerado como um concatenador de
strings, ao inv&eacute;s disso &eacute; usado para converter argumentos para n&uacute;meros
e executar adi&ccedil;&otilde;es n&uacute;mericas. Use <literal>"."</literal> para concatenar.
</simpara>
</listitem>
</itemizedlist>
<example>
<title>Migration from 2.0: concatenation for strings</title>
<title>Migrando do 2.0: concatena&ccedil;&atilde;o de strings</title>
<programlisting role="php">
<![CDATA[
echo "1" + "1";
]]>
</programlisting>
<para>
In PHP 2.0 this would echo 11, in PHP 3.0 it would
echo 2. Instead use:
No PHP 2.0 isto retornaria echo 11, no PHP 3.0 isto
retornar&aacute; echo 2. Ao inv&eacute;s disso use:
<programlisting role="php">
<![CDATA[
echo "1"."1";
@ -358,7 +345,7 @@ echo $a + $b;
</programlisting>
</para>
<para>
This would echo 2 in both PHP 2.0 and 3.0.
Isto ir&aacute; retornar echo 2 em ambas vers&otilde;es do PHP 2.0 e 3.0.
<programlisting role="php">
<![CDATA[
$a = 1;
@ -366,7 +353,7 @@ $b = 1;
echo $a.$b;
]]>
</programlisting>
This will echo 11 in PHP 3.0.
Isto retornar&aacute; echo 11 no PHP 3.0.
</para>
</example>
</section>

View file

@ -1,43 +1,43 @@
<?xml version="1.0" encoding="iso-8859-1"?>
<!-- $Revision: 1.25 $ -->
<!-- $Revision: 1.26 $ -->
<appendix id="migration4">
<title>Migrating from PHP 3 to PHP 4</title>
<title>Migrando do PHP 3 para o PHP 4</title>
<section id='migration4.changes'>
<title>What has changed in PHP 4</title>
<title>O que mudou no PHP 4</title>
<para>
PHP 4 and the integrated Zend engine have greatly improved PHP's
performance and capabilities, but great care has been taken to
break as little existing code as possible. So migrating your code
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
some hints about what to look for.
O PHP 4 e a integra&ccedil;&atilde;o com o engine Zend melhoraram incrivelmente a
performance e potencialidades do PHP, mas foi tomado o cuidado
de deixar o c&oacute;digo existente o m&aacute;ximo poss&iacute;vel. Sendo assim, migrar seu
c&oacute;digo do PHP 3 para PHP 4 &eacute; muito mais f&aacute;cil do que migrar do PHP/FI 2 para PHP 3.
Muitos c&oacute;digos existentes do PHP 3 podem rodar sem altera&ccedil;&otilde;es, mas voc&ecirc; dever&aacute;
ficar atento as diferenta&ccedil;as e ter o cuidado de testar seu c&oacute;digo antes de trocar as
vers&otilde;es nos sistemas de produ&ccedil;&otilde;es. O material abaixo dever&aacute; dar &agrave;
voc&ecirc; algumas instru&ccedil;&otilde;es sobre o que procurar.
</para>
</section>
<section id="migration4.php4.with.php3">
<title>Running PHP 3 and PHP 4 concurrently</title>
<title>Rodando PHP 3 e PHP 4 simultaneamente</title>
<simpara>
Recent operating systems provide the ability to perform
versioning and scoping. This features make it possible to let
PHP 3 and PHP 4 run as concurrent modules in one Apache server.
Os sistemas operacionais atuais fornecem a habilidade de de
executar "versioning" e "scoping". Estas caracter&iacute;sticas
tornam poss&iacute;vel deixar-mos o PHP 3 e PHP 4 rodando simultaneamente
como m&oacute;dulos em um s&oacute; servidor Apache.
</simpara>
<simpara>
This feature is known to work on the following platforms:
Esta op&ccedil;&atilde;o &eacute; suportada nas seguintes plataformas:
</simpara>
<itemizedlist>
<listitem><simpara>Linux with recent binutils (binutils 2.9.1.0.25 tested) </simpara></listitem>
<listitem><simpara>Solaris 2.5 or better</simpara></listitem>
<listitem><simpara>FreeBSD (3.2, 4.0 tested)</simpara></listitem>
<listitem><simpara>Linux com os recentes binutils (binutils 2.9.1.0.25 testado) </simpara></listitem>
<listitem><simpara>Solaris 2.5 ou superior</simpara></listitem>
<listitem><simpara>FreeBSD (3.2, 4.0 testado)</simpara></listitem>
</itemizedlist>
<para>
To enable it, configure PHP3 and PHP4 to use APXS
(--with-apxs) and the necessary link extensions
(--enable-versioning). Otherwise, all standard installations
instructions apply. For example:
Para habilitar isto, configure seu PHP 3 e PHP 4 usando o APXS
(--with-apxs) e linkar as extens&otilde;es necess&aacute;rias (--enable-versioning).
Por outro lado, isto tamb&eacute;m se aplica para todas as instala&ccedil;&otilde;es padr&otilde;es.
Por exemplo:
<informalexample>
<programlisting role="configure">
<![CDATA[
@ -53,15 +53,15 @@ $ ./configure \
</section>
<section id="migration4.configuration">
<title>Migrating Configuration Files</title>
<title>Migrando os arquivos de configura&ccedil;&atilde;o</title>
<para>
The global configuration file, <filename>php3.ini</filename>,
has changed its name to &php.ini;.
O arquivo de configura&ccedil;&atilde;o global, <filename>php3.ini</filename>,
foi alterado para ete nome &php.ini;.
</para>
<para>
For the Apache configuration file, there are slightly more
changes. The MIME types recognized by the PHP module have
changed.
Para o arquivo de configura&ccedil;&atilde;o do Apache, h&aacute; algumas pequenas
mudan&ccedil;as. Os tipos de MIME reconhecidos pelo m&oacute;dulo do PHP foram
alterados.
<informalexample>
<programlisting role="apache">
<![CDATA[
@ -72,9 +72,9 @@ application/x-httpd-php3-source --> application/x-httpd-php-source
</informalexample>
</para>
<para>
You can make your configuration files work with both versions
of PHP (depending on which one is currently compiled into the
server), using the following syntax:
Você pode fazer seu arquivo de configuração trabalhar com ambas as
versões do PHP (dependendo de qual compilação está no servidor),
usando a seguinte sintaxe:
<informalexample>
<programlisting>
<![CDATA[
@ -88,11 +88,11 @@ AddType application/x-httpd-php-source .phps
</informalexample>
</para>
<simpara>
In addition, the PHP directive names for Apache have changed.
Al&eacute;m disso, os nomes das diretiva do PHP para o Apache foram alteradas.
</simpara>
<para>
Starting with PHP 4.0, there are only four Apache directives
that relate to PHP:
Come&ccedil;ando com o PHP 4.0, h&aacute; quatro diretivas para o Apache relacionadas
ao PHP:
<informalexample>
<programlisting role="apache">
<![CDATA[
@ -105,17 +105,23 @@ php_admin_flag [PHP directive name] [On|Off]
</informalexample>
</para>
<simpara>
There are two differences between the Admin values and the non admin values:
H&aacute; duas diferen&ccedil;as entre os valores do Admin e do n&atilde;o admin:
</simpara>
<itemizedlist>
<listitem><simpara>Admin values (or flags) can only appear in the server-wide apache configuration files (e.g., httpd.conf).</simpara></listitem>
<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>
<listitem><simpara>Os valores Admin (ou os flags) s&oacute; aparecem no server-wide dos arquivos de configura&ccedil;&atilde;o
do apache (e.g., httpd.conf).</simpara></listitem>
<listitem><simpara>Os valores padr&otilde;es (ou os flags) n&atilde;o podem controlar determinadas diretivas do PHP,
por exemplo - safe mode (se voc&ecirc; pude-se cancelar as configura&ccedil;&otilde;es do modo seguro em arquivos .htacces,
isto desativaria o modo-seguro). Em contraste, os valores Admin podem modificar qualquer diretiva do PHP.</simpara></listitem>.
</itemizedlist>
<simpara>
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.
Para tornar o processo de transi&ccedil;&atilde;o mais f&aacute;cil, o PHP 4 vem com scripts que convertem automaticamente
suas configura&ccedil;&otilde;es do Apache e arquivos .htacces para trabalharem com ambos PHP 3 e PHP 4. Estes scripts
N&Atilde;O convertem as linhas do tipo MIME! Voc&ecirc; ter&aacute; que converter manualmente.
</simpara>
<para>
To convert your Apache configuration files, run the apconf-conv.sh script (available in the scripts/apache/ directory). For example:
Para converter seus arquivos de configura&ccedil;&atilde;o do Apache, rode o script apconf-conv.sh (distpon&iacute;vel no
diret&oacute;rio /scripts/apache). Exemplo:
<informalexample>
<programlisting role="shell">
<![CDATA[
@ -125,10 +131,11 @@ php_admin_flag [PHP directive name] [On|Off]
</informalexample>
</para>
<simpara>
Your original configuration file will be saved in httpd.conf.orig.
Seu arquivo de configura&ccedil;&atilde;o original ser&aacute; salve como httpd.conf.orig.
</simpara>
<para>
To convert your .htaccess files, run the aphtaccess-conv.sh script (available in the scripts/apache/ directory as well):
Para converter seus arquivos .htaccess, rode o script aphtaccess-conv.sh (dispon&iacute;vel no
diret&oacute;rio scripts/apache), exemplo:
<informalexample>
<programlisting role="shell">
<![CDATA[
@ -138,315 +145,316 @@ php_admin_flag [PHP directive name] [On|Off]
</informalexample>
</para>
<simpara>
Likewise, your old .htaccess files will be saved with an .orig prefix.
Como j&aacute; foi dito, seus antigos arquivos .htacces ser&atilde;o salvos com o prefixo .orig.
</simpara>
<simpara>
The conversion scripts require awk to be installed.
A convers&atilde;o dos scripts requer que o awk esteja instalado.
</simpara>
</section>
<section id='migration4.parser'>
<title>Parser behavior</title>
<title>Comportamento da Análise</title>
<para>
Parsing and execution are now two completely separated steps, no
execution of a files code will happen until the complete file and
everything it requires has completely and successfully been
parsed.
A execução e a análise são agora duas etapas completamente separadas,
nenhuma execução de código de arquivo será acontecerá até que tudo seja
completado e analisado completamente.
</para>
<para>
One of the new requirements introduced with this split is that
required and included files now have to be syntactically
complete. You can no longer spread the different controlling parts
of a control structure across file boundaries. That is you cannot
start a <literal>for</literal> or <literal>while</literal> loop,
an <literal>if</literal> statement or a <literal>switch</literal>
block in one file and have the end of loop,
<literal>else</literal>, <literal>endif</literal>,
<literal>case</literal> or <literal>break</literal> statements in
a different file.
Uma das novas exig&ecirc;ncias introduzidas com este split &eacute; que
arquivos requeridos e inclu&iacute;dos agora tem que estar sintaticamente
completos. Voc&ecirc; n&atilde;o pode mais espalhar os em diferentes partes os
controles de estrutura ou espalahar os controles atrav&eacute;s de arquivos.
Voc&ecirc; n&atilde;o pode come&ccedil;ar um la&ccedil;o <literal>for</literal> ou <literal>while</literal>,
um bloco de instru&ccedil;&otilde;es <literal>if</literal> ou <literal>switch</literal> come&ccedil;ando
em um arquivo e terminar o loop, <literal>else</literal>, <literal>endif</literal>,
<literal>case</literal> ou <literal>break</literal> em um arquivo diferente.
</para>
<para>
It still perfectly legal to include additional code within loops
or other control structures, only the controlling keywords and
corresponding curly braces <literal>{...}</literal> have to be
within the same compile unit (file or <function>eval</function>ed
string).
Ainda &eacute; permitido incluir c&oacute;digos adicionaisdentro dos la&ccedil;os ou
estruturas de controle, somente os controles chaves e os correspondentes
<literal>(....)</literal> tem que estar compilados na mesma unidade
(arquivo ou <function>eval</function>ed string).
</para>
<para>
This should not harm to much as spreading code like this should be
considered as very bad style anyway.
Isto n&atilde;o deve prejudicar muito considerando que um c&oacute;digo como este
&eacute; considerado mal feito de qualquer maneira.
</para>
<para>
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.
Outra coisa que n&atilde;o &eacute; mais poss&iacute;vel, e que &eacute; raramente visto em um c&oacute;digo
PHP 3 &eacute; o retorno de valores de um requerido arquivo. Retornar valores
de um arquivo inclu&iacute;do ainda &eacute; poss&iacute;vel.
</para>
</section>
<section id='migration4.error-reporting'>
<title>Error reporting</title>
<title>Relatório de erros</title>
<section id='migration4.error-reporting.config'>
<title>Configuration changes</title>
<title>Mudan&ccedil;as na Configura&ccedil;&atilde;o</title>
<para>
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.
O relat&oacute;rio de erro do PHP 3 foi ajustado para um simples
valor n&uacute;mero formado pela soma de n&uacute;meros relacionados aos
diferentes n&iacute;veis de erro. Valores usuais onde 15 para relatar
todos os erros e mensagens ou 7 para relatar qualquer coisa mas
simples observa&ccedil;&atilde;o ao mal estilo e coisas como esta.
</para>
<para>
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.
PHP 4 cont&eacute;m um maior n&iacute;vel de erros e avisos e vem com uma
configura&ccedil;&atilde;o do parser que agora permite que constantes simb&oacute;licas
sejam usadas para para ajustar ao comportamente pretendido.
</para>
<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
<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 &php.ini;: <literal>error_reporting =
E_ALL &amp; ~ ( 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 &amp; ~ ( E_NOTICE | E_WARNING
)</literal>.
O n&iacute;vel do relat&oacute;rio de erro agora pode ser configurado explicitamente
removendo os n&iacute;veis de advert&ecirc;ncia que voc&ecirc; n&atilde;o quer gerar nas suas
mensagens de erro x-oring da constante simb&oacute;lica <literal>E_ALL</literal>.
Parece complicado? Bem, vamos dizer que voc&ecirc; quer todas as advert&ecirc;ncias
categorizadas na constante simb&oacute;lica <literal>E_NOTICE</literal>. Ent&atilde;o voc&ecirc;
dever&aacute; colocar o seguinte em seu &php.ini;: <literal>error_reporting =
E_ALL &amp; - ( E_NOTICE )</literal>. Se voc&ecirc; quiser suprir as
advert&ecirc;ncias voc&ecirc; deve adicionar a constante apropriada dentro do
par&ecirc;ntese usando o operador '|':
<literal>erro_reporting = E_ALL &amp; ~ ( E_NOTICE | E_WARNING )</literal>.
</para>
<warning>
<para>
When upgrading code or servers from PHP 3 to PHP 4 you should
check these settings and calls to
<function>error_reporting</function> or you might disable
reporting the new error types, especially E_COMPILE_ERROR. This
may lead to empty documents without any feedback of what happened
or where to look for the problem.
Ao atualizar c&oacute;digos ou servidores do PHP 3 para PHP 4 voc&ecirc;
deve checar as configura&ccedil;&otilde;es e chamadas ao <function>error_reporting</function>
ou voc&ecirc; deve desabilitar os novos tipos de relat&oacute;rio de erro,
especialmente E_COMPILE_ERROR. Isto pode ocasionar a limpeza de
documents sem nenhuma resposta do que ocorreu ou onde procurar
pelo problema.
</para>
</warning>
<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 parse errors. This may lead to very strange
behavior as scripts might no longer work without error messages
showing up anywhere.
Usando valores menores que 7 ou 15 para ajustar o relat&oacute;rio
de erro n&atilde;o &eacute; uma boa id&eacute;ia porque pode suprir algumas das
classes de erros adicionadas no parser de erros. Isto pode causar
um comportamento estranho com os scripts e tamb&eacute;m n&atilde;o ir&aacute;
mostrar nenhuma mensagem de erro em nenhum lugar.
</para>
<para>
This has lead to a lot of unreproducible bug reports in the
past where people reported script engine problems they were not
capable to track down while the &true; case was usually some
missing '}' in a required file that the parser was not able to
report due to a misconfigured error reporting system.
No passa isto causou muitas inconveni&ecirc;ncias porque as
pessoas relatavam problemas nos scripts e na verdade
n&atilde;o eram capazes de consertar erros comuns, como a falta de
um '}' requerido em um arquivo que era passado e que o
parser n&atilde;o era capaz de reportar um erro que era apenas
um erro de uma falta de configura&ccedil;&atilde;o no sistema.
</para>
<para>
So checking your error reporting setup should be the first thing
to do whenever your scripts silently die. The Zend engine can
be considered mature enough nowadays to not cause this kind of
strange behavior.
Ent&atilde;o checar a sua configura&ccedil;&atilde;o do relat&oacute;rio de erros
deve ser a primeira coisa a fazer quando os seus scripts
causam erros silenciosos. O engine da Zend pode ser
considerado maduro o bastante nos dias atuais para n&atilde;o
causar estes tipos de erros estranhos.
</para>
</warning>
</section>
<section id='migration4.error-reporting.additions'>
<title>Additional warning messages</title>
<title>Mensagens de advert&ecirc;ncia adicionais</title>
<para>
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 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.
Muitos c&oacute;digos PHP 3 existentes usam uma linguagem de estrutura
que pode ser considerado um c&oacute;digo mal formatado, o que pode
tornar as coisas f&aacute;ceis agora, pode facilmente ser quebrado
por mudan&ccedil;as em outros lugares. PHP 4 exibe muitas mensagens
de advert&ecirc;ncia em situa&ccedil;&otilde;es onde o PHP 3 n&atilde;o o fazia. O jeito
f&aacute;cil de consertar isto &eacute; setar para off as mensagens E_NOTICE,
mas geralmente &eacute; sempre bom consertar o c&oacute;digo.
</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
and 4 will fall back to interpret these 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 will now warn you whenever you use unquoted
string constants as for example in
<literal>$_SERVER[REQUEST_METHOD]</literal>. Changing it
to <literal>$_SERVER['REQUEST_METHOD']</literal> will
make the parser happy and greatly improve the style and security
of your code.
O caso mais comum que agora ir&aacute; produzir mensagens de advert&ecirc;ncia
&eacute; o uso de constantes de strings n&atilde;o quotadas como &iacute;ndices de array.
Ambos PHP 3 e PHP 4 tentar&atilde;o interpretarar isto como se fosse strings
se nenhuma palavra ou constante for conhecida pelo nome, mas sempre que
uma constante por esse nome for definida em qualquer lugar do c&oacute;digo
ela pode causar erros no script. Isto pode se tornar um risco de
seguran&ccedil;a se um invasor redefinir as strings constantes &agrave; um
caminho que faz o seu script dar as permiss&otilde;es corretas que ele
n&atilde;o deveria ter. Ent&atilde;o o PHP 4 agora avisa voc&ecirc; sempre que
voc&ecirc; usar strings constantes n&atilde;o quotadas por exemplo no
<literal>$_SERVER[REQUEST_METHOD]</literal>. Altere isto para
<literal>$_SERVER['REQUEST_METHOD']</literal> que far&aacute;
com que o parser fique feliz e melhorar&aacute; extremamente o
estilo e seguran&ccedil;a do seu c&oacute;digo.
</para>
<para>
Another thing PHP 4 will now tell you about is the use of
uninitialized variables or array elements.
Outra coisa que o PHP 4 agora lhe informa &eacute; sobre o uso
de vari&aacute;veis ou elementos de array n&atilde;o inicializados.
</para>
</section>
</section>
<section id='migration4.initializers'>
<title>Initializers</title>
<title>Inicializadores</title>
<para>
Static variable and class member initializers only accept scalar
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.
Os inicializadores de vari&aacute;veis est&aacute;ticas e membros de classes
aceitam somente valores escalares enquanto no PHP 3 eles aceitavam
qualquer express&atilde;o v&aacute;lida. Isto &eacute;, mais uma vez, devido ao corte entre
a execu&ccedil;&atilde;o e o parsing como nenhum c&oacute;digo executado quando o parser
v&ecirc; o inicializador.
</para>
<para>
For classes you should use constructors to initialize member
variables instead. For static variables anything but a simple
static value rarely makes sense anyway.
Para classes voc&ecirc; deve usar construtores para inicializar
membros ao inv&eacute;s de vari&aacute;veis. Para vari&aacute;veis est&aacute;ticas
pode-se usar qualquer coisa mas raramente uma simples
vari&aacute;vel est&aacute;tira faz algum sentido.
</para>
</section>
<section id='migration4.empty'>
<title><literal>empty("0")</literal></title>
<para>
The perhaps most controversial change in behavior has happened 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.
Talvez a mudan&ccedil;a mais controversa no comportamento aconteceu na fun&ccedil;&atilde;o
<function>empty</function>. Uma string que cont&eacute;m somente caracteres
' 0 ' (zero) agora &eacute; considerada vazia enquanto no PHP 3 ela n&atilde;o era.
</para>
<para>
This new behavior makes sense in web applications, with all input
fields returning strings even if numeric input is requested, and
with PHP's capabilities of automatic type conversion. But on the
other had it might break your code in a rather subtle way,
leading to misbehavior that is hard to track down if you do not
know about what to look for.
Estes novos comportamentos fazem sentido em aplicativos web, com todos
aqueles campos retornando strings mesmo se entradas n&uacute;mericas s&atilde;o requisitadas,
e com as capacidades do PHP automaticamente converter os tipos. Mas
por outro lado isto pode gerar problemas no seu c&oacute;digo de uma
maneira totalmente pertubadora, conduzindo ao um estranho comportamento
que &eacute; duro de consertar se voc&ecirc; n&atilde;o souber o que voc&ecirc; procura.
</para>
</section>
<section id='migration4.missing'>
<title>Missing functions</title>
<title>Fun&ccedil;&otilde;es abandonadas</title>
<para>
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 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
ported yet and finally some functions or extensions may be missing
due to license conflicts.
Enquanto o PHP 4 vem com uma s&eacute;rie de novas caracter&iacute;sticas,
fun&ccedil;&otilde;es e extens&otilde;es, voc&ecirc; talvez encontre algumas fun&ccedil;&otilde;es da
vers&atilde;o 3 que n&atilde;o existem mais. Um pequeno n&uacute;mero de fun&ccedil;&otilde;es
do n&uacute;cleo desapareceu porque elas n&atilde;o funcionavam com o novo
sistema de execu&ccedil;&atilde;o e parsing introduzido na vers&atilde;o 4 com a
Zend engine. Outras fun&ccedil;&otilde;es e mesmo extens&otilde;es se tornaram
obsoletas para as novas fun&ccedil;&otilde;es e extens&otilde;es que servem a
mesma tarefa melhor e/ou de uma maneira geral. Algumas fun&ccedil;&otilde;es
simplesmente n&atilde;o foram portadas ainda e finalmente algumas
fun&ccedil;&otilde;es ou extens&otilde;es podem ter sido retiradas por conflitos
de licen&ccedil;a.
</para>
<section id='migration4.missing.concept'>
<title>Functions missing due to conceptual changes</title>
<title>Funções abandonadas devido à mudanças conceptuais</title>
<para>
As PHP 4 now separates 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 happened by
then. So the function <function>short_tags</function> no longer
exists. You can still change the parsers behavior by setting
appropriate values in the &php.ini; file.
Como o PHP 4 agora separa o parsing da execu&ccedil;&atilde;o n&atilde;o &eacute; mais poss&iacute;vel
alterar o comportamento do parser (agora embutido na Zend engine)
na hora da execu&ccedil;&atilde;o quando o parsing j&aacute; aconteceu. Ent&atilde;o a fun&ccedil;&atilde;o
<function>short_tags</function> n&atilde;o existe mais. Voc&ecirc; ainda
pode mudar o comportamento dos parsers setando o valor
propriedade no arquivo &php.ini.
</para>
<para>
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.
Outra caracter&iacute;sticas do PHP 3 que n&atilde;o faz parte do PHP 4 &eacute;
a rela&ccedil;&atilde;o embutida de eliminar erros. Existem add-ons de terceiros
para a Zend engine que adicionam um funcionamento similar.
</para>
</section>
<section id='migration4.deprecate'>
<title>Deprecate functions and extensions</title>
<title>Depcritamento de fun&ccedil;&otilde;es e extens&otilde;es</title>
<para>
The Adabas and Solid database extensions are no more. Long live
the unified ODBC extension instead.
As extens&otilde;es dos banco de dados Adabas e Solid n&atilde;o existem mais.
Ao in&eacute;s delas foi unificado o ODBC.
</para>
</section>
<section id='migration4.unset'>
<title>Changed status for <function>unset</function></title>
<title>Mudan&ccedil;a de status para <function>unset</function></title>
<para>
<function>unset</function>, although still available, is
implemented as a language construct rather than a function.
<function>unset</function>, embora ainda dispon&iacute;vel, &eacute;
implementado como um construtor de linguagem melhor que uma fun&ccedil;&atilde;o.
</para>
<para>
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>.
Isto n&atilde;o tem nenhumas conseq&uuml;&ecirc;ncias no comportamento < de function>unset, mas testar para "unset" usando < function>function_exists retornar&aacute; o &false; porque com outras constru&ccedil;&otilde;es da l&iacute;ngua que olham como fun&ccedil;&otilde;es tais como < function>echo.
Isto n&atilde;o interfere em nada no comportamento do
<function>unset</function>, mas testar "unset" usando
<function>function_exists</function> retornar&aacute; &false;
porque com outros construtores de linguagens que observam
func&ccedil;&otilde;es tais como o <function>echo</function>.
</para>
<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.
Uma otura mudan&ccedil;a mais pr&aacute;tica &eacute; que n&atilde;o &eacute; mais poss&iacute;vel chamar
<function>unset</function> indiretamente, isso &eacute;, <literal>$func="unset"; $func($algumavar)</literal>
n&atilde;o ir&aacute; mais funcionar.
</para>
</section>
</section>
<section id='migration4.extensions'>
<title>PHP 3 extension</title>
<title>Extens&otilde;es PHP 3</title>
<para>
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.
Extens&otilde;es escritas para o PHP 3 n&atilde;o ir&atilde;o funcionar com o PHP 4,
nem como bin&aacute;rias nem no c&oacute;digo fonte. N&atilde;o &eacute; dif&iacute;cil portar estas
extens&otilde;es para o PHP 4 se vc&ecirc; tiver acesso aos fontes originais.
Uma descri&ccedil;&atilde;o detalhada do processo de porta&ccedil;&atilde;o n&atilde;o faz parte deste
texto.
</para>
</section>
<section id='migration4.strings'>
<title>Variable substitution in strings</title>
<title>Substitui&ccedil;&atilde;o de vari&aacute;veis nas strings</title>
<para>
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.
O PHP 4 adiciona um novo mecanimos para a substitui&ccedil;&atilde;o
de vari&aacute;veis em strings. Agora voc&ecirc; finalmente pode acessar
as vari&aacute;veis de um objeto membro e seus elementos de um
array multidimensional dentro de strings.
</para>
<para>
To do so you have to enclose your variables with curly braces with
the dollar sign immediately following the opening brace:
Para fazer isso voc&ecirc; tem que incluir nas suas vari&aacute;veis chaves
com o s&iacute;mbolo da moeda imediatamente ap&oacute;s a chave de abertura:
<literal>{$...}</literal>
</para>
<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 you had to use something like <literal>"text
".$obj-&gt;member." text"</literal>.
Para embutir o valor de um objeto membro de uma vari&aacute;vel
dentro de uma string simplesmente escreva <literal>"texto {$obj-&gt;membro} texto"</literal>
enquanto no PHP 3 voc&ecirc; tinha que usar uma coisa como esta
<literal>"texto ".$obj-&gt;membro." texto"</literal>.
</para>
<para>
This should lead to more readable code, while it may break
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 favorite search-and-replace
tool.
</para>
Isto gera um c&oacute;digo mais leg&iacute;vel, mas pode gerar problemas
em scripts existentes escritos para o PHP 3. Mas
voc&ecirc; pode facilmente char este tipo de problema procurando
por uma combina&ccedil;&atilde;o de caracteres <literal>{$</literal>
no seu c&oacute;digo e substituindo eles por
<literal>\{$</literal> usando sua ferramenta de
procura-e-substitui&ccedil;&atilde;o favorita.
</para>
</section>
<section id='migration4.cookies'>
<title>Cookies</title>
<para>
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 habit and creates the cookie header lines in
exactly the same order as you set the cookies in the code.
O PHP 3 tinha um mau h&aacute;bito de configurar os cookies na ordem
reversa das chamadas <function>setcookie</function> no seu c&oacute;digo.
O PHP 4 inibiu este mau h&aacute;bito e cria as linhas de cabe&ccedil;alhos
dos cookies exatamente na mesma ordem que voc&ecirc; definie no
seu c&oacute;digo.
</para>
<para>
This might break some existing code, but the old behaviour was so
strange to understand that it deserved a change to prevent further
problems in the future.
Isto pode gerar problemas no seu c&oacute;digo existente, mas o velho
comportamente era t&atilde;o estranho de se entender que mereceu
uma mudan&ccedil;a para previnir futuros problemas.
</para>
</section>
<section id='migration4.variables'>
<title>Handling of global variables</title>
<title>Manipula&ccedil;&atilde;o de vari&aacute;veis globais</title>
<para>
While handling of global variables had the focus on to be easy in
PHP 3 and early versions of PHP 4, the focus has changed to be more
secure. While in PHP 3 the following example worked fine, in PHP 4 it
has to be unset($GLOBALS["id"]);. This is only one issue of global
variable handling. You should always have used $GLOBALS, with
newer versions of PHP 4 you are forced to do so in most cases.
Read more on this subject in the <link linkend="references.global">
<literal>global</literal> references section</link>.
A manipula&ccedil;&atilde;o de vari&aacute;veis globais tinha o foco de ser
f&aacute;cil no PHP 3 e vers&otilde;es posteriores &agrave; PHP 4, mas este
foco mudou por medidas de seguran&ccedil;a. Enquanto em um
script PHP 3 o exemplo a seguir funciona normalmente,
no PHP 4 tem que se usar unset($GLOBALS["id"]);. Isto
&eacute; apenas uma introdu&ccedil;&atilde;o da manipula&ccedil;&atilde;o de vari&aacute;veis globais.
Voc&ecirc; dever&aacute; sempre usar $GLOBALS, com as novas vers&otilde;es
do PHP 4 voc&ecirc; &eacute; for&ccedil;ado a fazer isto na maioria dos casos.
Leia mais sobre este assunto em <link linkend="references.global">.
</para>
<example>
<title>Migration of global variables</title>
<title>Migra&ccedil;&atilde;o das vari&aacute;veis globais</title>
<programlisting role="php">
<![CDATA[
<?php

File diff suppressed because it is too large Load diff

View file

@ -1,15 +1,15 @@
<?xml version="1.0" encoding="iso-8859-1"?>
<!-- $Revision: 1.2 $ -->
<!-- $Revision: 1.3 $ -->
<refentry id="reserved.constants.core">
<refnamediv>
<refname>Core Predefined Constants</refname>
<refpurpose>Constants defined in the PHP core, Zend, and SAPI modules</refpurpose>
<refname>Constantes Pr&eacute;-definidas do N&uacute;cleo</refname>
<refpurpose>Constantes definidas no n&uacute;cleo do PHP, Zend, e m&oacute;dulos SAPI</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<title>Descri&ccedil;&atilde;o</title>
<simpara>
These constants are defined by the PHP core. This includes PHP,
the Zend engine, and SAPI modules.
Estas constantes s&atilde;o definidas pelo n&uacute;cleo do PHP. Isto
inclui o PHP, a Zend engine, e os m&oacute;dulos SAPI.
</simpara>
<variablelist>
<varlistentry>

View file

@ -1,5 +1,5 @@
<?xml version="1.0" encoding="iso-8859-1"?>
<!-- $Revision: 1.4 $ -->
<!-- $Revision: 1.5 $ -->
<!-- DOCNOTE: some constants listed here are also there at
reference/info/constants.xml. Further decision is needed
@ -8,13 +8,13 @@
deleted from here to have a consistent standard constants list. -->
<refentry id="reserved.constants.standard">
<refnamediv>
<refname>Standard Predefined Constants</refname>
<refpurpose>Constants defined in PHP by default</refpurpose>
<refname>Constantes Padr&otilde;es Pr&eacute;-definidas</refname>
<refpurpose>Constantes definidas no PHP por padr&atilde;o</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<title>Descri&ccedil;&atilde;o</title>
<simpara>
These constants are defined in PHP by default.
Estas constantes s&atilde;o definidas por padr&atilde;o no PHP.
</simpara>
<variablelist>
<varlistentry>

View file

@ -1,23 +1,23 @@
<?xml version="1.0" encoding="iso-8859-1"?>
<!-- $Revision: 1.27 $ -->
<!-- $Revision: 1.28 $ -->
<appendix id="resource">
<title>List of Resource Types</title>
<title>Lsita de Tipos de Recursos</title>
<para>
The following is a list of functions which create, use or destroy
PHP resources. The function <function>is_resource</function> can be
used to determine if a variable is a resource and
<function>get_resource_type</function> will return the type of
resource it is.
A seguir h&aacute; uma lista de fun&ccedil;&otilde;es que criam, usam e destr&oacute;em
recursos do PHP. A fun&ccedil;&atilde;o <function>is_resource</function> podem
ser usadas para determinar se a vari&aacute;vel &eacute; um recurso e
o <function>get_resource_type</function> ir&aacute; retornar o tipo
de recurso que est&aacute; sendo usado.
<table>
<title>Resource Types</title>
<title>Tipos de Recursos</title>
<tgroup cols="5">
<thead>
<row>
<entry>Resource Type Name</entry>
<entry>Created By</entry>
<entry>Used By</entry>
<entry>Destroyed By</entry>
<entry>Definition</entry>
<entry>Nome do Tipo de Recurso</entry>
<entry>Criado por</entry>
<entry>Usado por</entry>
<entry>Destro&iacute;do por</entry>
<entry>Defini&ccedil;&atilde;o</entry>
</row>
</thead>
<tbody>

View file

@ -1,17 +1,18 @@
<?xml version="1.0" encoding="iso-8859-1"?>
<!-- $Revision: 1.7 $ -->
<!-- $Revision: 1.8 $ -->
<appendix id="tokens">
<title>List of Parser Tokens</title>
<title>Lista dos Símbolos od Parse</title>
<para>
Various parts of the PHP language are represented internally by types like
T_SR. PHP outputs identifiers like this one in parse errors, like
<literal>"Parse error: unexpected T_SR, expecting ',' or ';' in script.php on line 10."</literal>
V&aacute;rias partes da linguagem PHP s&atilde;o representadas internamente por
tipos como T_SR. Como estas sa&iacute;das de identificadores do PHP nos
erros do parse, como <literal>"Parse error: unexpected T_SR, expecting ',' or ';' in
script.php on line 10."</literal>
</para>
<para>
You're supposed to know what T_SR means. For everybody who doesn't
know that, here is a table with those identifiers, PHP-syntax and
references to the appropriate places in the manual.
Você supostamente já deve sar o que T_SR significa. Para quem
não sabe, aqui vai uma tabela de seus identificadores, sintaxe-PHP
e as referências apropriadas colocadas no manual.
</para>
<table>
<title>Tokens</title>