Tynambule

Depuis PHP 5.2, il n’est plus possible de récupérer l’ID interne d’un objet via un cast en string sans avoir implémenté de méthode __toString sur ledit objet.

Ancienne méthode:

1
2
3
4
5
6
7

class foo {
    public function __construct() {
        echo "Hi, it's me!";
    }
}
$bar = new foo();
print $bar;

Auparavant, ce snippet renvoyait l’ID interne de l’objet. Désormais, et c’est plus propre comme ça, il lance une erreur fatale récuperable (« Catchable fatal error: Object of class foo could not be converted to string in filename on line n« ). Mais du coup, on perd un moyen simple et efficace de savoir à quelle instance d’un objet on a affaire, ce qui peut être très utile dans un processus de debug.

Fort heureusement, les gentils monsieurs de PHP ont implémenté une fonction qui permet de refaire la même chose: spl_object_hash() ! Hé ben voilà, le monde est sauvé. Allez, salut.

En nos temps où l’orienté-objet est roi, un schéma de fonctionnement revient régulièrement :

Un objet dont chaque instance correspond à une ligne en base. On charge les données lors de l’initialisation de l’objet (dans son constructeur), puis on les sauvegardes lorsque l’on a fini de les modifier.

La problématique est la suivante : mais quand a-t-on fini de les modifier? Dans 99% des cas, « ça dépend« . Les méthodes pour implémenter cette notion sont légions: une méthode genre save que l’on appelle « à la fin« , une sauvegarde systématique à chaque modification, et la rationnelle mais risquée sauvegarde dans le destructeur de l’objet.

Cette dernière méthode semble la plus intéressante, puisqu’elle défini avec une presque certitude la notion de « fin » de modifications. Toutefois, dans notre contexte orienté objet, il y a de fortes chances que l’on utilise un objet pour se connecter à la base de donnée. Et cet objet fermera probablement sa connexion dans le destructeur. Et comment savoir que la base est encore connectée lors de l’exécution du destructeur de notre objet de données? C’est le drame.

Lire la suite…