êtes-vous prêt pour les bonbons de citrouille et le cidre? L'Halloween annuel est là! Bien que le fanatisme du monde entier ne soit pas aussi bon que les états-Unis, je veux toujours partager des conseils PHP "horribles" pour célébrer ce festival. Ce message est facile et amusant et vous montrera certains des comportements surprenants (mais logiques) de PHP lui-même, ainsi que ces fa?ons effrayantes (et peut-être très illogiques) que certaines personnes utilisent PHP pour effectuer des taches. Vous pouvez le considérer comme mon cadeau de vacances, un peu de ?bonbons spirituels? du programmeur - après tout, pourquoi les enfants de bonbons uniquement qui ne donnent pas toutes les spécialités?

Résumé des points clés

• PHP peut présenter un comportement inattendu, tel que la conservation des références en dehors de la première boucle foreach, entra?nant des résultats de sortie inattendus. Ce problème peut être atténué en réaffectant la cha?ne à l'aide des clés du tableau.
• Lorsque vous utilisez PHP pour effectuer des taches plus complexes (telles que les scripts shell), il est crucial de comprendre comment l'environnement d'exécution est cloné lors de la fourche et comment les différentes ressources sont affectées dans tous les processus. Par exemple, lors de la connexion à une base de données, il est préférable de se connecter dans le processus parent après le processus de l'enfant de la fourche, et le processus de l'enfant se connectera par lui-même si nécessaire.
• Le modèle Singleton (en fait rien de plus que des variables globales orientées objet sophistiqué) peut rendre le débogage difficile. Il est recommandé d'éviter le mode Singleton dans la mesure du possible.
• Bien que les pratiques de codage non conventionnelles comme ?PHP effrayante? soient intéressantes et éducatives, elles ne sont généralement pas considérées

tableau de bizarrerie

Il était une fois, dans un studio de développement pas si lointain, Arthur écrivait toujours du code tard dans la nuit. Il ne savait pas que le tableau qu'il était sur le point d'utiliser était hanté! Avec chaque robinet sur le clavier, il sentit un froid glisser de sa colonne vertébrale, mais il a bêtement ignoré cette subtile prémonition.

<?php
$spell = array("double", "toil", "trouble", "cauldron", "bubble");
foreach ($spell as &$word) {
    $word = ucfirst($word);
}
foreach ($spell as $word) {
    echo $word . "n";
}

D'accord, ce tableau n'est pas vraiment hanté, mais la sortie est en effet inattendue:

<code>Double
Toil
Trouble
Cauldron
Cauldron</code>

La raison de ce comportement "terrifiant" est de savoir comment PHP conserve les références en dehors de la première boucle foreach. Lorsque la deuxième boucle commence, $word est toujours une référence, pointant vers le dernier élément du tableau. La première itération de la deuxième boucle attribue "double" à $word, qui écrase le dernier élément. La deuxième itération attribue "le travail" à $word, en remplissant à nouveau le dernier élément. Lorsque la boucle lit la valeur du dernier élément, elle a été remplacée plusieurs fois. Pour avoir un aper?u de ce comportement, je recommande de lire le billet de blog de Johannes Schlüter sur le sujet, "Références et Foreach". Vous pouvez également exécuter cette version légèrement modifiée et vérifier sa sortie pour mieux comprendre ce que fait PHP:

<?php
$spell = array("double", "toil", "trouble", "cauldron", "bubble");
foreach ($spell as &$word) {
    $word = ucfirst($word);
}
foreach ($spell as $word) {
    echo $word . "n";
}

Arthur a appris une le?on très importante cette nuit-là et a corrigé son code avec les clés du tableau pour réaffecter la cha?ne:

<code>Double
Toil
Trouble
Cauldron
Cauldron</code>

Connexion de la base de données fant?mes

PHP est de plus en plus demandé non seulement de générer des pages Web chaque jour. Le nombre de scripts shell écrits en PHP augmente, et les taches effectuées par ces scripts deviennent de plus en plus complexes, car les développeurs voient les avantages de l'intégration des langages de développement. En règle générale, les performances de ces scripts sont acceptables et les compromis effectués pour la commodité sont prouvés. Susan écrit donc une tache de traitement parallèle dont le code est similaire à ce qui suit:

<?php
$spell = array("double", "toil", "trouble", "cauldron", "bubble");
foreach ($spell as &$word) {
    $word = ucfirst($word);
}
var_dump($spell);
foreach ($spell as $word) {
    echo join(" ", $spell) . "n";
}

son code alimente les processus de l'enfant pour effectuer des travaux de longue durée en parallèle, tandis que le processus parent continue de surveiller les processus de l'enfant et rapporte les résultats lorsque tous les enfants se terminent.

<?php
foreach ($spell as $key => $word) {
    $spell[$key] = ucfirst($word);
}

Cependant, les dirigeants de Susan lui ont demandé de journaliser les informations sur l'état dans le journal au lieu de les sortir en sortie standard. Susan a prolongé son code à l'aide d'un mécanisme de connexion de la base de données PDO motif Singleton qui était déjà inclus dans la base de code de l'entreprise.

#! /usr/bin/env php
<?php
$pids = array();
foreach (range(0, 4) as $i) {
    $pid = pcntl_fork();
    if ($pid > 0) {
        echo "Fork child $pid.n";
        // record PIDs in reverse lookup array
        $pids[$pid] = true;
    } else if ($pid == 0) {
        echo "Child " . posix_getpid() . " working...n";
        sleep(5);
        exit;
    }
}
// wait for children to finish
while (count($pids)) {
    $pid = pcntl_wait($status);
    echo "Child $pid finished.n";
    unset($pids[$pid]);
}
echo "Tasks complete.n";

Susan s'attend à voir des lignes dans le tableau timings mise à jour; processus. Malheureusement, l'exécution lance une exception et la base de données ne reflète pas ses attentes.

<code>Fork child 1634.
Fork child 1635.
Fork child 1636.
Child 1634 working...
Fork child 1637.
Child 1635 working...
Child 1636 working...
Fork child 1638.
Child 1637 working...
Child 1638 working...
Child 1637 finished.
Child 1636 finished.
Child 1638 finished.
Child 1635 finished.
Child 1634 finished.
Tasks complete.</code>

#! /usr/bin/env php
<?php
$db = Db::connection();
$db->query("UPDATE timings SET tstamp=NOW() WHERE name='start time'");

$pids = array();
foreach (range(0, 4) as $i) {
    ...
}
while (count($pids)) {
    ...
}

$db->query("UPDATE timings SET tstamp=NOW() WHERE name='stop time'");

class Db
{
    protected static $db;

    public static function connection() {
        if (!isset(self::$db)) {
            self::$db = new PDO("mysql:host=localhost;dbname=test",
                "dbuser", "dbpass");
            self::$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
        }
        return self::$db;
    }
}

Comme le tableau d'Arthur, la base de données de Susan est-elle hantée? Eh bien, si je vous donne les indices suivants, voyez si vous pouvez reconstituer ce mystère: 1. Lorsqu'un processus est fourche, le processus parent est copié en tant que processus enfant. Ces processus répliqués s'exécutent ensuite en parallèle à partir de ce moment. 2. Les membres statiques sont partagés entre tous les cas de la classe.

PDO est enveloppée en singleton, donc toute référence dans l'application pointe la même ressource en mémoire. DB::connection() Renvoie d'abord la référence de l'objet, la fourche du processus parent, le processus de l'enfant continue de traiter, tandis que le processus parent attend, le processus de l'enfant se termine et PHP nettoie les ressources utilisées, puis le processus parent essaie d'utiliser l'objet de base de données encore. La connexion à MySQL a été fermée dans le processus de l'enfant, donc l'appel final échoue. Essayer na?vement d'obtenir la connexion avant la dernière requête de journalisation n'aidera pas Susan car la même instance PDO échouée sera retournée car c'est un singleton. Je recommande d'éviter les singletons - ce ne sont vraiment que des variables mondiales axées sur les objets, ce qui rend le débogage difficile. Même dans notre cas, la connexion sera toujours fermée par le processus de l'enfant, mais si DB::connection() est appelé avant la deuxième requête, il renverra au moins une nouvelle connexion sans singleton. Mais une meilleure fa?on consiste à comprendre comment l'environnement d'exécution est cloné lors de la fourche et comment les différentes ressources sont affectées dans tous les processus. Dans ce cas, il est préférable de se connecter à la base de données dans le processus parent après le processus de l'enfant de la fourche, et le processus de l'enfant se connectera par lui-même si nécessaire. Les connexions ne doivent pas être partagées.

<code>PHP Fatal error:  Uncaught exception 'PDOException' with message 'SQLSTATE[HY000]: General error: 2006 MySQL server has gone away' in /home/susanbrown/test.php:21
Stack trace:
#0 /home/susanbrown/test.php(21): PDO->query('UPDATE timers S...')
#1 {main}</code>

dr.

"Frankenstein" de Mary Shelley raconte l'histoire d'un scientifique créant la vie, mais il se sent dégo?té de sa laideur et l'abandonne. Après une mort et une destruction inutiles, le Dr Frankenstein poursuit sa création jusqu'à la fin du monde, essayant de le détruire. Beaucoup d'entre nous ont donné une vie en code aussi laide que nous souhaitons plus tard que nous pourrions y échapper - le code est si laid, si terne, si chaotique qu'il nous donne envie de vomir, mais il veut juste l'amour et la compréhension. Il y a quelques années, j'ai joué avec une idée des interfaces de base de données et à quoi ils ressembleraient s'ils suivaient plus strictement la philosophie d'Unix de "tout est un fichier": les requêtes seront écrites dans "Fichier", les ensembles de résultats seront être lu à partir du "fichier". Une chose mène à une autre, après une partie de ma propre mort et de mon codage destructeur, j'ai écrit la classe suivante qui a peu à voir avec mes pensées initiales:

<?php
$spell = array("double", "toil", "trouble", "cauldron", "bubble");
foreach ($spell as &$word) {
    $word = ucfirst($word);
}
foreach ($spell as $word) {
    echo $word . "n";
}

<code>Double
Toil
Trouble
Cauldron
Cauldron</code>