mardi 1 décembre 2015

PHP et ./configure

Aujourd’hui, j’ai fait un brew install (je sais, je suis un dingue) qui a mis à jour la bibliothèque icu, utilisée par l’extension int de PHP.

Du coup, PHP est devenu inutilisable sur mon poste de travail puisque j’obtenais systématiquement la sympathique erreur suivante :

# php -v
dyld: Library not loaded: /usr/local/opt/icu4c/lib/libicui18n.55.dylib
Referenced from: /usr/local/bin/php
Reason: image not found
Trace/BPT trap : 5

L’erreur peut semble quelque peu incompréhensible au premier abord, mais l’expérience m’a appris qu’elle veut tout simplement dire que l’exécutable PHP n’est pas capable de localiser la bibliothèque libicui18n.55.dylib à l’emplacement indiqué lors de sa compilation, ce qui est logique vu que brew a supprimé le fichier concerné au profit de libicui18n.56.dylib (et oui, les bibliothèques qui contiennent leur numéro de version dans leur nom sont une plaie).

Lire la suite

mardi 19 juin 2012

À propos de PSR-0, PSR-1 et PSR-2

Depuis quelques mois, les recommandations du PHP Framework Interoperability Group, ex PHP Working Group, ont beaucoup gagné en visibilité dans le monde des développeurs PHP grâce notamment à la mise en œuvre de la PSR-0 par composer et au travail de Fabien Potencier.

Pour rappel, PSR-0 a pour but d'éviter la mise en œuvre de plusieurs mécanismes d'auto-chargement de classe lorsque l'on utilise des composants provenant de projets différents.

Pour cela, elle définie un certain nombre de règles concernant à la fois le nom des fichiers, leur contenu ainsi que leur organisation.

Cette recommandation a maintenant plusieurs années, mais elle était restée confidentielle jusqu'à ce que composer la démocratise et elle fait maintenant pratiquement partie du vocabulaire courant des développeurs PHP, à tel point qu'elle a été l'un des principaux sujets de discussion au cours du dernier forum PHP, aussi bien parmi les conférenciers que parmi les visiteurs.

Fort de ce succès, le PHP Framework Interoperability Group a donc poursuivi ses travaux et a rédigé les recommandations PSR-1 et PSR-2, qui sont, de mon point de vue et à contrario, de la merde !

Lire la suite

mercredi 18 août 2010

PHP manque de plus en plus de cohérence

PHP est un langage connu pour avoir un certain nombre d'incohérences, à la fois au niveau de sa syntaxe et de son fonctionnement.

Au niveau syntaxique, il y a par exemple le cas des fonctions permettant la manipulation des chaînes de caractères, qui ne suivent pas une convention de nommage rigoureuse.

C'est la raison pour laquelle il existe, par exemple, une fonction strpos() et une fonction str_pad().

L'ordre des arguments peut également être variable d'une fonction à une autre, alors qu'elles sont toutes les deux du même domaine fonctionnel.

Ainsi, array_search() et strpos() permettent toutes deux de localiser un élément parmi plusieurs, mais l'ordre de leurs deux premiers arguments est inversé.

Au niveau de son fonctionnement, les incohérences sont certes moins nombreuses, mais à mon sens plus vicieuses.

Si celle concernant l'impossibilité de spécifier autre chose qu'une classe ou un tableau comme type d'argument pour une fonction ou une méthode n'est pas trop méchante, celle ne permettant pas de définir une méthode de classe abstraite imposée par une interface l'est beaucoup plus.

Autre incohérence pénible, il n'est pas possible d'appeler directement une fonction anonyme ou une fermeture si cette dernière est une propriété d'un objet.

Évidement, cette liste d'incohérence est loin d'être exhaustive, d'autant qu'elle s’enrichit régulièrement grâce aux nouvelles fonctionnalités supportées par le langage au fur et à mesure des versions.

Ainsi, Wilfried Ceron, dont j'ai fais l'interview récemment, m'a permis d'en découvrir une nouvelle, via l'utilisation de la méthode magique __invoke(), disponible depuis PHP 5.3.0.

Lire la suite

jeudi 8 juillet 2010

Les fermetures, c'est trop... fermé !

J'utilise actuellement intensivement les fermetures, plus connues sous leur dénomination anglaise closure, dans mes développements PHP.

Elles sont en effet extrêmement bien adapté à mon besoin, mais je viens de découvrir qu'elles ont un inconvénient de taille.

Lire la suite

lundi 4 janvier 2010

Y'a t'il un physicien spécialisé dans l'imagerie parmi mes lecteurs ?

Pour l'un de mes projets chez no parking, j'ai besoin de manipuler des images.

Je suis donc en train de regarder dans le détail la documentation de l'extension imagick de PHP, histoire de comparer cette dernière avec l'extension gd.

Lire la suite

- page 1 de 3