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:

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.

Deux fois ce soir, eh bien, c'est un jour faste.

J'ai eut besoin pour la barre de progression AJAX de récupérer la taille d'un fichier distant sur un serveur HTTP. La fonction filesize() de PHP ne permettant pas de vérifier la taille d'une cible sur HTTP, j'ai du me rabattre sur une solution plus manuelle.

Je suis tombée dans la doc' sur une fonction utilisant la librairie CURL. Mais bon, CURL, c'est pas standard, et puis c'était trop facile...

Je travaille en ce moment sur deux projets qui ont à gérer des upload de fichiers depuis le client vers le serveur, et les téléchargements de fichiers depuis un serveur distant. Le gros problème du transfert de fichier avec PHP, c'est que l'on n'a aucune information sur l'état du transfert ou de l'upload.

Une BOM, ou Byte-Order Mark, c'est le code de caractères U+FEFF au début d'un flux de données, genre un fichier. BOM, c'est un instrument de torture de l'Unicode. Il est sensé permettre d'établir simplement en regardant les premiers bits d'un flux quel est l'encodage de ce flux. Il existe basiquement autant de BOM que de spécifications différentes de l'Unicode, c'est à dire quelques tetrachiées.

Et les BOM sont viles...