dams Fri Feb 16 08:50:41 2001 EDT
Modified files:
/phpdoc/fr/appendices migration4.xml
Log:
Corrected some typos.Removed illegal chars..
Index: phpdoc/fr/appendices/migration4.xml
diff -u phpdoc/fr/appendices/migration4.xml:1.2 phpdoc/fr/appendices/migration4.xml:1.3
--- phpdoc/fr/appendices/migration4.xml:1.2 Mon Feb 12 07:19:15 2001
+++ phpdoc/fr/appendices/migration4.xml Fri Feb 16 08:50:41 2001
@@ -1,289 +1,289 @@
<appendix id="migration4">
<title>Migration de PHP 3.0 à PHP 4.0</title>
<sect1 id="migration4.changes">
- <title>Ce qui a changŽ en PHP 4.0</title>
+ <title>Ce qui a changé en PHP 4.0</title>
<para>
- PHP 4.0 et le moteur Zend ont significativement amŽliorŽ les
- performances et les possibilitŽs de PHP, tout en assurant une
- compatibilitŽ ascendante maximale. Le maximum de codes existants
- sous PHP 3.0 fonctionneront sous PHP 4.0. La migration de votre
- code de PHP 3.0 vers PHP 4.0 sera beaucoup plus facile que
- celle de PHP/FI 2.0 vers 3.0. Un grand nombre de scripts seront
- prts sans modifications, mais il est bon que vous connaissiez
- les quelques diffŽrences, et que vous testiez vos applications
- avant d'effecteur le changement de cadre de production. Les
- indications suivantes vous mettront sur la voie.
+ PHP 4.0 et le moteur Zend ont significativement amélioré les
+ performances et les possibilités de PHP, tout en assurant une
+ compatibilité ascendante maximale. Le maximum de codes existants
+ sous PHP 3.0 fonctionneront sous PHP 4.0. La migration de votre
+ code de PHP 3.0 vers PHP 4.0 sera beaucoup plus facile que
+ celle de PHP/FI 2.0 vers 3.0. Un grand nombre de scripts seront
+ prêts sans modifications, mais il est bon que vous connaissiez
+ les quelques différences, et que vous testiez vos applications
+ avant d'effecteur le changement de cadre de production. Les
+ indications suivantes vous mettront sur la voie.
</para>
</sect1>
<sect1 id="migration4.parser">
<title>Comportement de l'analyseur</title>
<para>
- L'analyse et l'Žxecution sont dŽsormais deux Žtapes complŽtement
- dissociŽes, et l'ŽxŽcution intervient lorsque le code, ainsi que
- tous ses inclusions et prŽ-requis, ont ŽtŽ
- complŽtement analysŽ et validŽ.
- </para>
- <para>
- Une des nouvelles conditions introduites est que les fichiers
- inclus et requis (<function>include</function> et
- <function>require</function>) doivent tre syntaxiquement
- complets. Vous ne pouvez plus rŽpartir diffŽrents cas de votre
- code dans plusieurs fichiers. Vous ne pouvez plus commner une
- boucle <literal>for</literal> ou <literal>while</literal>,
- une condition <literal>if</literal> ou un cas <literal>switch</literal>
- dans un fichier, et finir la boucle ou placer les cas
- <literal>else</literal>, <literal>endif</literal>,
- <literal>case</literal> ou <literal>break</literal>
- dans un autre fichier.
- </para>
- <para>
- Il est toujours valable d'inclure du code supplŽmentaire depuis
- une boucle ou dans une conditions, mais les accolades de
- bloc <literal>{...}</literal>, et les ŽlŽments de la boucle
- doivent tre dans le mme fichier ou cha”ne ŽvaluŽe avec
- <function>eval</function>.
- </para>
- <para>
- Cela ne devrait pas perturber trop de monde, car Žtaler son
- code de cette faon est plut™t un style ˆ Žviter.
- </para>
- <para>
- Une autre nouveautŽ est qu'il est plus possible de faire
- retourner une valeur avec un fichier requis
(<function>require</function>)
- (mais c'est plut™t rare en PHP 3.0). Retourner une valeur
- avec un fichier inclus (<function>require</function>) est toujours
- possible.
+ L'analyse et l'éxecution sont désormais deux étapes
+complétement
+ dissociées, et l'éxécution intervient lorsque le code,
+ainsi que
+ tous ses inclusions et pré-requis, ont été
+ complétement analysés et validés.
+ </para>
+ <para>
+ Une des nouvelles conditions introduites est que les fichiers
+ inclus et requis (<function>include</function> et
+ <function>require</function>) doivent être syntaxiquement
+ complets. Vous ne pouvez plus répartir différents cas de votre
+ code dans plusieurs fichiers. Vous ne pouvez plus commner une
+ boucle <literal>for</literal> ou <literal>while</literal>,
+ une condition <literal>if</literal> ou un cas <literal>switch</literal>
+ dans un fichier, et finir la boucle ou placer les cas
+ <literal>else</literal>, <literal>endif</literal>,
+ <literal>case</literal> ou <literal>break</literal>
+ dans un autre fichier.
+ </para>
+ <para>
+ Il est toujours valable d'inclure du code supplémentaire depuis
+ une boucle ou dans une conditions, mais les accolades de
+ bloc <literal>{...}</literal>, et les éléments de la boucle
+ doivent être dans le même fichier ou chaîne
+évaluée avec
+ <function>eval</function>.
+ </para>
+ <para>
+ Cela ne devrait pas perturber trop de monde, car étaler son
+ code de cette façon est plutôt un style à éviter.
+ </para>
+ <para>
+ Une autre nouveauté est qu'il est plus possible de faire
+ retourner une valeur avec un fichier requis (<function>require</function>)
+ (mais c'est plutôt rare en PHP 3.0). Retourner une valeur
+ avec un fichier inclus (<function>inclus</function>) est toujours
+ possible.
</para>
</sect1>
<sect1 id="migration4.errors">
<title>Rapport d'erreur</title>
<sect2 id="migration4.error_reporting">
- <title>Changement de configuration</title>
- <para>
- Avec PHP 3.0, le niveau de rapport d'erreur Žtait obtenu en
- ajoutant les constantes numŽriques de chaque niveau de
- rapport. GŽnŽralement, on utilisait 15 pour afficher toutes
- les erreurs, et 7 pour afficher toutes les erreurs hormis
- les alertes simples.
- </para>
- <para>
- PHP 4.0 dispose d'un nombre significativement plus grand de niveaux
- de rapport d'erreur, et l'analyseur comprend dŽsormais les
- constantes, lors des modifications.
- </para>
- <para>
- Le niveau de rapport d'erreur doit dŽsormais tre explicitement
- configurŽ en supprimant les niveaux dont vous ne voulez pas
- du niveau maximal, gr‰ce ˆ la fonction de OU exclusif. Ca a
- l'air compliquŽ? Supposons que vous souhaitiez afficher toutes les
- erreurs, hormis les alertes de style, qui sont repŽrŽes par
- la constante : E_NOTICE. Il suffit d'ajouter la valeur
- suivante dans le fichier <filename>php.ini</filename>:
- <literal>error_reporting = E_ALL & ~ ( E_NOTICE )</literal>.
- Si vous voulez supprimer en plus les alertes, vous pouvez
- ajouter la constante appropriŽe, en la combinant avec l'opŽrateur
- OU logique '|':
- <literal>error_reporting= E_ALL & ~ ( E_NOTICE | E_WARNING )</literal>.
- </para>
- <warning>
- <para>
- L'utilisation des vieilles valeurs de 7 et 15 est une trs
- mauvaise idŽe, car elles ne prennent pas en compte les
- nouvelles classes d'erreurs, y compris certaines erreurs
- d'analyse. Cela peut conduire ˆ de trs Žtranges rŽsultats,
- o le script n'affiche plus rien, malgrŽ une erreur d'analyse.
- </para>
- <para>
- Cela a conduit ˆ un grand nombre de rapport d'erreur dans
- le passŽ, alors que les programmeurs n'Žtaient tout simplement
- pas capable de repŽrer l'accolade manquante, car l'analyseur
- avait la consigne de cacher ces erreurs.
- </para>
- <para>
- VŽrifier votre niveau d'erreur doit tre le premier reflexe
- lorsque vos scripts meurent silencieusement. Le moteur
- Zend est considŽrŽ actuellement comme suffisament mature pour
- ne plus causer ce genre de problme aujourd'hui.
- </para>
- </warning>
+ <title>Changement de configuration</title>
+ <para>
+ Avec PHP 3.0, le niveau de rapport d'erreur était obtenu en
+ ajoutant les constantes numériques de chaque niveau de
+ rapport. Généralement, on utilisait 15 pour afficher toutes
+ les erreurs, et 7 pour afficher toutes les erreurs hormis
+ les alertes simples.
+ </para>
+ <para>
+ PHP 4.0 dispose d'un nombre significativement plus grand de niveaux
+ de rapport d'erreur, et l'analyseur comprend désormais les
+ constantes, lors des modifications.
+ </para>
+ <para>
+ Le niveau de rapport d'erreur doit désormais être explicitement
+ configuré en supprimant les niveaux dont vous ne voulez pas
+ du niveau maximal, grâce à la fonction de OU exclusif. Ca a
+ l'air compliqué? Supposons que vous souhaitiez afficher toutes les
+ erreurs, hormis les alertes de style, qui sont repérées par
+ la constante : E_NOTICE. Il suffit d'ajouter la valeur
+ suivante dans le fichier <filename>php.ini</filename>:
+ <literal>error_reporting = E_ALL & ~ ( E_NOTICE )</literal>.
+ Si vous voulez supprimer en plus les alertes, vous pouvez
+ ajouter la constante appropriée, en la combinant avec l'opérateur
+ OU logique '|':
+ <literal>error_reporting= E_ALL & ~ ( E_NOTICE | E_WARNING )</literal>.
+ </para>
+ <warning>
+ <para>
+ L'utilisation des vieilles valeurs de 7 et 15 est une très
+ mauvaise idée, car elles ne prennent pas en compte les
+ nouvelles classes d'erreurs, y compris certaines erreurs
+ d'analyse. Cela peut conduire à de très étranges
+résultats,
+ où le script n'affiche plus rien, malgré une erreur
+d'analyse.
+ </para>
+ <para>
+ Cela a conduit à un grand nombre de rapport d'erreur dans
+ le passé, alors que les programmeurs n'étaient tout
+simplement
+ pas capable de repérer l'accolade manquante, car l'analyseur
+ avait la consigne de cacher ces erreurs.
+ </para>
+ <para>
+ Vérifier votre niveau d'erreur doit être le premier
+reflexe
+ lorsque vos scripts meurent silencieusement. Le moteur
+ Zend est considéré actuellement comme suffisament mature
+pour
+ ne plus causer ce genre de problème aujourd'hui.
+ </para>
+ </warning>
</sect2>
<sect2 id="migration4.messages">
- <title>Nouveaux messages d'erreurs</title>
- <para>
- Un grand nombre de scripts PHP PHP 3.0 utilisent des structures qui
- doivent tre considŽrŽes comme un trs mauvais style, mme s'il
- effectue bien la t‰che qui lui est affectŽe, car ils ne sont pas
- robustes. PHP 4.0 affichera de nombreux messages d'erreurs dans
- des situations o PHP 3.0 restera coi.
- La solution de facilitŽ consiste ˆ supprimer les messages de
- niveau E_NOTICE, mais c'est une meilleure idŽe de corriger le
- code ˆ la place.
- </para>
- <para>
- Le cas le plus courant qui gŽnŽrera des messages d'alertes
- est l'utilisation de constantes sans guillemets comme
- index de tableaux. PHP 3.0, comme PHP 4.0, finiront par les
- interprŽter literalement comme des cha”nes, si aucune constante
- n'est dŽfinie ˆ la place. Mais si jamais une telle constante
- est dŽfinie dans une autre partie du code, cela risque de
- produire des rŽsultats Žtonnants. Cela peut devenir un trou
- de sŽcuritŽ si un pirate arrive ˆ redŽfinir les constantes
- de telle manire que le script lui donne accs ˆ un niveau
- de droits supŽrieur. PHP 4.0 vous signalera tout oubli de
- guillemets comme par exemple dans :
- <literal>$HTTP_SERVER_VARS[REQUEST_METHOD]</literal>. Modifier
- ce code e, <literal>$HTTP_SERVER_VARS['REQUEST_METHOD']</literal>
- rendra l'analyseur heureux, et amŽliorera grandement votre
- style et la sŽcuritŽ du code.
- </para>
- <para>
- PHP 4.0 vous signalera les variables ou les
- ŽlŽments de tableaux non initialisŽs.
- </para>
+ <title>Nouveaux messages d'erreurs</title>
+ <para>
+ Un grand nombre de scripts PHP PHP 3.0 utilisent des structures qui
+ doivent être considérées comme un très mauvais
+style, même s'il
+ effectue bien la tâche qui lui est affectée, car ils ne sont
+pas
+ robustes. PHP 4.0 affichera de nombreux messages d'erreurs dans
+ des situations où PHP 3.0 restera coi.
+ La solution de facilité consiste à supprimer les messages de
+ niveau E_NOTICE, mais c'est une meilleure idée de corriger le
+ code à la place.
+ </para>
+ <para>
+ Le cas le plus courant qui générera des messages d'alertes
+ est l'utilisation de constantes sans guillemets comme
+ index de tableaux. PHP 3.0, comme PHP 4.0, finiront par les
+ interpréter literalement comme des chaînes, si aucune constante
+ n'est définie à la place. Mais si jamais une telle constante
+ est définie dans une autre partie du code, cela risque de
+ produire des résultats étonnants. Cela peut devenir un trou
+ de sécurité si un pirate arrive à redéfinir les
+constantes
+ de telle manière que le script lui donne accès à un
+niveau
+ de droits supérieur. PHP 4.0 vous signalera tout oubli de
+ guillemets comme par exemple dans :
+ <literal>$HTTP_SERVER_VARS[REQUEST_METHOD]</literal>. Modifier
+ ce code en <literal>$HTTP_SERVER_VARS['REQUEST_METHOD']</literal>
+ rendra l'analyseur heureux, et améliorera grandement votre
+ style et la sécurité du code.
+ </para>
+ <para>
+ PHP 4.0 vous signalera les variables ou les
+ éléments de tableaux non initialisés.
+ </para>
</sect2>
</sect1>
<sect1 id="migration4.initializers">
<title>Initialiseur</title>
<para>
- Les variables statiques et les membres de classes n'acceptent
- plus que des initialiseurs scalaires, tandis que PHP 3.0 acceptait
- aussi les expressions. Cela est dž, encore une fois, ˆ la
- sŽparation de l'analyse et de l'exŽcution : aucun code
- ne peut tre exŽcutŽ tant que l'analye n'est pas terminŽe.
+ Les variables statiques et les membres de classes n'acceptent
+ plus que des initialiseurs scalaires, tandis que PHP 3.0 acceptait
+ aussi les expressions. Cela est dû, encore une fois, à la
+ séparation de l'analyse et de l'exécution : aucun code
+ ne peut être exécuté tant que l'analye n'est pas
+terminée.
</para>
<para>
- Pour les classes, il vaut mieux initialiser les membres dans
- le constructeur. Pour les variables static, une valeur fixe
- et simple est la seule chose qui viennent ˆ l'esprit.
+ Pour les classes, il vaut mieux initialiser les membres dans
+ le constructeur. Pour les variables static, une valeur fixe
+ et simple est la seule chose qui viennent à l'esprit.
</para>
</sect1>
<sect1 id="migration4.empty">
<title><literal>empty("0")</literal></title>
<para>
- L'Žvolution la plus polŽmique est celle de <function>empty</function>.
- Une cha”ne contenant seulement le caractre
- <literal>'0'</literal> (zŽro) est maintenant considŽrŽe comme
- vide, alors qu'elle ne l'Žtait pas en PHP 3.0.
+ L'évolution la plus polémique est celle de
+<function>empty</function>.
+ Une chaîne contenant seulement le caractère
+ <literal>'0'</literal> (zéro) est maintenant considérée
+comme
+ vide, alors qu'elle ne l'était pas en PHP 3.0.
</para>
<para>
- Ce nouveau comportement prend tout son send dans les applications
- web, puisque tous les rŽsultats de champs de type input est une
- cha”ne, mme si un nombre est demandŽ, et gr‰ce aux capacitŽs
- de conversion automatique de PHP. D'un autre cotŽ, cela peut
- casser votre code d'une manire trs subtile, menant droit au
- comportement erratique, difficilement repŽrable si vous ne
+ Ce nouveau comportement prend tout son sens dans les applications
+ web, puisque tous les résultats de champs de type input sont de type
+ une chaîne, même si un nombre est demandé, et ce,
+grâce aux capacités
+ de conversion automatique de PHP. D'un autre coté, cela peut
+ casser votre code d'une manière très subtile, menant droit au
+ comportement erratique, difficilement repérable si vous ne
savez pas ce qui vous attend.
- </para>
- </sect1>
- <sect1 id="migration4.missing">
- <title>Fonctions manquantes</title>
- <para>
- Bien que PHP 4.0 dispose de nombreuses nouvelles fonctionnalitŽs
- fonctions et extensions, vous vous rencontrer des fonctions PHP
- 3.0 qui manquent. Un petit nombre de fonctions de base n'ont pu
- tre portŽes en PHP 4.0, maintenant que l'analyse et l'ŽxŽcution
- ont ŽtŽ sŽparŽes. D'autres fonctions, et mmes des extensions
- entires sont maintenant obsoltes, remplacŽes par de nouvelles
- fonctions plus puissantes ou plus efficaces. Certaines fonctions
- n'ont tout simplement pas ŽtŽ portŽes pour le moment ou pour
- des raisons de licences.
- </para>
- <sect2 id="migration4.impossible">
- <title>Fonctions manquantes pour des raisons de structure</title>
- <para>
- Comme PHP 4.0 sŽpare l'analyse et l'ŽxŽcution, il n'est plus
- possible de modifier le comportement de l'analyseur (intŽgrŽ
- dans le moteur Zend) durant l'ŽxŽcution, puisque toute
- l'analyse a eu lieu, et est terminŽe. La fonction
- <function>short_tags</function> a cessŽ d'Žxister. Vous pouvez
- toujours modifier le comportement de l'analyseur avec
- le fichier <filename>php.ini</filename>.
- </para>
- <para>
- Une autre fonctionnalitŽ qui a disparu est le dŽbuggeur
- de PHP 3.0, comme dŽcrit dans un autre appendice. Un nouveau
- dŽbuggeur est promis par Zend, mais il n'a pas encore montrŽ
- le bout de son nez.
- </para>
+ </para>
+ </sect1>
+ <sect1 id="migration4.missing">
+ <title>Fonctions manquantes</title>
+ <para>
+ Bien que PHP 4.0 dispose de nombreuses nouvelles fonctionnalités
+ fonctions et extensions, vous vous rencontrer des fonctions PHP
+ 3.0 qui manquent. Un petit nombre de fonctions de base n'ont pu
+ être portées en PHP 4.0, maintenant que l'analyse et
+l'éxécution
+ ont été séparées. D'autres fonctions, et
+mêmes des extensions
+ entières sont maintenant obsolètes, remplacées par de
+nouvelles
+ fonctions plus puissantes ou plus efficaces. Certaines fonctions
+ n'ont tout simplement pas été portées pour le moment ou
+pour
+ des raisons de licences.
+ </para>
+ <sect2 id="migration4.impossible">
+ <title>Fonctions manquantes pour des raisons de structure</title>
+ <para>
+ Comme PHP 4.0 sépare l'analyse et l'éxécution, il n'est
+plus
+ possible de modifier le comportement de l'analyseur (intégré
+ dans le moteur Zend) durant l'éxécution, puisque toute
+ l'analyse a eu lieu, et est terminée. La fonction
+ <function>short_tags</function> a cessé d'éxister. Vous pouvez
+ toujours modifier le comportement de l'analyseur avec
+ le fichier <filename>php.ini</filename>.
+ </para>
+ <para>
+ Une autre fonctionnalité qui a disparu est le débuggeur
+ de PHP 3.0, comme décrit dans un autre appendice. Un nouveau
+ débuggeur est promis par Zend, mais il n'a pas encore montré
+ le bout de son nez.
+ </para>
</sect2>
<sect2 id="migration4.deprecated">
- <title>Fonctions et extensions obsoltes</title>
- <para>
- Les extensions Adabas et Solid n'existent plus. Elle sont intŽgrŽes
- dans les fonctions ODBC UnifiŽ.
- </para>
+ <title>Fonctions et extensions obsolètes</title>
+ <para>
+ Les extensions Adabas et Solid n'existent plus. Elle sont
+intégrées
+ dans les fonctions ODBC Unifié.
+ </para>
</sect2>
<sect2 id="migration4.unset">
- <title>Nouveau statut pour <function>unset</function></title>
- <para>
- <function>unset</function>, bient que toujours disponible, a ŽtŽ
- implŽmentŽ lŽgrement diffŽremment en PHP 4.0, et elle n'est
- plus vraiment une 'fonction'.
- </para>
- <para>
- Cela n'a pas de consŽquence directe sur le comportement de
- <function>unset</function>, mais utiliser cette fonction
- pour faire un test avec <function>function_exists</function>
- retournera <literal>FALSE</literal> comme il se doit avec
- les fonction bas niveau comme <function>echo</function>.
- </para>
- <para>
- Une autre application pratique disparue est qu'il n'est plus possible
- d'appeler <function>unset</function> indirectement, c'est ˆ dire que
- <literal>$func="unset"; $func($somevar)</literal> ne fonctionne plus.
- </para>
+ <title>Nouveau statut pour <function>unset</function></title>
+ <para>
+ <function>unset</function>, bient que toujours disponible, a
+été
+ implémenté légèrement différemment en
+PHP 4.0, et elle n'est
+ plus vraiment une 'fonction'.
+ </para>
+ <para>
+ Cela n'a pas de conséquence directe sur le comportement de
+ <function>unset</function>, mais utiliser cette fonction
+ pour faire un test avec <function>function_exists</function>
+ retournera <literal>FALSE</literal> comme il se doit avec
+ les fonction bas niveau comme <function>echo</function>.
+ </para>
+ <para>
+ Une autre application pratique disparue est qu'il n'est plus possible
+ d'appeler <function>unset</function> indirectement, c'est à dire que
+ <literal>$func="unset"; $func($somevar)</literal> ne fonctionne plus.
+ </para>
</sect2>
</sect1>
<sect1 id="migration4.extension">
<title>Extensions PHP 3.0</title>
<para>
- Les extensions Žcrites pour PHP 3.0 ne fonctionnent plus avec PHP 4.0,
- ni les exŽcutables, ni les codes sources. Il n'est pas difficile de
- porter les extensions de PHP 3.0 ˆ 4.0 si vous avez accs aux
- sources originales. Une description dŽtaillŽe du processus
- de portage ne fait pas partie de cet appendice (pour le moment).
+ Les extensions écrites pour PHP 3.0 ne fonctionnent plus avec PHP 4.0,
+ ni les exécutables, ni les codes sources. Il n'est pas difficile de
+ porter les extensions de PHP 3.0 à 4.0 si vous avez accès aux
+ sources originales. Une description détaillée du processus
+ de portage ne fait pas partie de cet appendice (pour le moment).
</para>
</sect1>
<sect1 id="migration4.substitution">
- <title>Substitution de variables dans les cha”nes</title>
+ <title>Substitution de variables dans les chaînes</title>
<para>
- PHP 4.0 dispose d'un nouveau mŽcanisme de substitution des
- variables dans les cha”nes. Vous pouvez dŽsormais accŽder aux
- membres d'objets et aux tableaux multidimensionnels dans une
- cha”ne.
+ PHP 4.0 dispose d'un nouveau mécanisme de substitution des
+ variables dans les chaînes. Vous pouvez désormais
+accéder aux
+ membres d'objets et aux tableaux multidimensionnels dans une
+ chaîne.
</para>
<para>
- Pour cela, il suffit de placer la variables entre accolades, le signe
- $ suivant immŽdiatement la premire accolade :
- <literal>{$variable['a']}</literal>
+ Pour cela, il suffit de placer la variables entre accolades, le signe
+ $ suivant immédiatement la première accolade :
+ <literal>{$variable['a']}</literal>
</para>
<para>
- Pour utiliser la valeur d'un membre d'objet dans une cha”ne,
- il suffit d'Žcrire : <literal>"text {$obj->member} text"</literal>;
- alors qu'en PHP 3.0, il fallait faire comme ceci :
- <literal>"texte".$objet->membre." texte"</literal>.
+ Pour utiliser la valeur d'un membre d'objet dans une chaîne,
+ il suffit d'écrire : <literal>"text {$obj->member} text"</literal>;
+ alors qu'en PHP 3.0, il fallait faire comme ceci :
+ <literal>"texte".$objet->membre." texte"</literal>.
</para>
<para>
- Cette technique rend le code beaucoup plus lisible, mais risque de
- poser des problmes dans certains scripts PHP 3.0. Vous pouvez
- facilement traquer ce problme en recherche les sŽquences
- <literal>{$</literal> dans votre code, et en les remplacant par
- <literal>\{$</literal> avec votre outil de remplacement habituel.
+ Cette technique rend le code beaucoup plus lisible, mais risque de
+ poser des problèmes dans certains scripts PHP 3.0. Vous pouvez
+ facilement traquer ce problème en recherche les séquences
+ <literal>{$</literal> dans votre code, et en les remplacant par
+ <literal>\{$</literal> avec votre outil de remplacement habituel.
</para>
</sect1>
<sect1 id="migration4.cookies">
<title>Cookies</title>
<para>
- PHP 3.0 avait la mauvaise habitude d'envoyer les cookies dans l'ordre
- inverse de celui du code (l'orde des appels ˆ
- <function>setcookie</function>). PHP 4.0 rŽtablit l'ordre naturel
- en les envoyant dans le mme ordre que vous mmes.
+ PHP 3.0 avait la mauvaise habitude d'envoyer les cookies dans l'ordre
+ inverse de celui du code (l'orde des appels à
+ <function>setcookie</function>). PHP 4.0 rétablit l'ordre naturel
+ en les envoyant dans le même ordre que vous mêmes.
</para>
<para>
- Cela peut aussi prendre ˆ contre-pied certains programmes, mais
- ce comportement Žtait tellement Žtrange qu'il mŽritait un tel
- traitement un jour ou l'autre, pour Žviter d'autres
- problmes ultŽrieurs.
+ Cela peut aussi prendre à contre-pied certains programmes, mais
+ ce comportement était tellement étrange qu'il méritait
+un tel
+ traitement un jour ou l'autre, pour éviter d'autres
+ problèmes ultérieurs.
</para>
</sect1>
</appendix>
