Carnet de notes

Catégorie : PHP

  • Flysys­tem – accès aux systèmes de fichier au PHP

    Petite décou­verte récente et sympa : Flysys­tem. Une biblio­thèque de code PHP qui présente une abstrac­tion assez simple et sympa autour des systèmes de fichier locaux, S3, drop­box, FTP, …

  • Docu­men­ta­tion PHP

    Quelques (nombreux) écrans de présen­ta­tion de Willian Durand à propos de PHP

    Je ne sais pas à qui est destiné cette docu­men­ta­tion, mais c’est un boulot énorme et très bien fait de collecte, analyse et présen­ta­tion des bonnes pratiques. Vous devriez passer dessus et prendre du temps à lire même si vous travaillez déjà avec PHP au jour le jour.

    Pour m’être frotté à ce genre d’exer­cice, j’ai rare­ment vu un résul­tat aussi bon.

    Il y a une version pour la suite qui parle plus parti­cu­liè­re­ment de Symfony, mais moins essen­tielle à mon avis.

  • Please stop preten­ding PHP is a good language

    The first step to fixing a problem is admit­ting that there is one.

    Bon, des critiques de PHP ce n’est pas ce qui manque mais pour une raison incon­nue je m’étais dit que ça partait bien quand j’ai lu la première ligne. Sauf qu’au final…

    • It’s not ok that you can’t relia­bly get the first element of an array using less than 4 lines of code without causing side effects.*[1]
    • It’s not ok that the output of echo 5/3 might depend on the coun­try you live in if you don’t know the fine details of confi­gu­ring PHP.
    • It’s not ok that you won’t be able can’t call array_map” or just “$itera­tor->reduce” on an itera­tor in 2014.
    • It’s not ok to ignore the simple fact that most of the PHP world currently relies on parsing func­tion and class comments for it’s code to func­tion because people can’t get their shit toge­ther on mailing lists.
    • It’s not ok to run around shou­ting “type hinting for lite­rals would mean that passing an int to float hint would fatal PHP” and calling that an reaso­nable argu­ment while people just write $x = (float)$x; in the cases where it actually does matter anyways.
    • It’s not ok to be not able to talk to 2 back end data sources in paral­lel, using “promises” or whate­ver, in a language that has “pull stuff out of data­base and put it into the inter­net” as a proclai­med core compe­tency.
    • It’s not ok that echo 0.000001; produces 1.0E-6 and that casting it to string doesn’t help but putting quotes around it does.
    • It’s not ok that you have to clear the error buffer by gene­ra­ting a suppres­sed unde­fi­ned variable error just to be able to sanely use token_get_all().

    Au final la moitié des items ressemblent juste à « ça ne fait pas ce que j’es­père ». Alors pour ceux qui m’ont fait suivre le lien :

    Pour le premier item il existe plusieurs solu­tions, dont un simple array_values($tab)[0]. Bref, rien d’ex­cep­tion­nel pour aller itérer sur un diction­naire.

    Pour le second, si on demande expli­ci­te­ment au niveau du système à affi­cher les résul­tats suivant les conven­tions d’un pays spéci­fique, PHP s’y conforme. C’est le cas de la plupart des langages, y compris la ligne de commande de base. Diffi­cile d’avan­cer que c’est un problème, d’au­tant qu’il est bien évidem­ment possible d’igno­rer la confi­gu­ra­tion du système pour forcer une locale au niveau du langage.

    Quant à savoir comment affi­cher 0.000001 ou 1E-6, comme le langage n’a aucun moyen de savoir comment a été tapé la valeur initiale dans le code source (rien de spéci­fique à PHP, à ma connais­sance aucun ne le fait), il faut bien qu’il choi­sisse une forme arbi­trai­re­ment à la sortie. Si l’au­teur veut forcer autre chose, il a tous les outils pour ça.

    Pour le dernier item j’ai la flemme de véri­fier les cas limites mais à priori c’est juste que l’au­teur n’a pas eu le courage d’al­ler créer un gestion­naire d’er­reur pour gérer ses erreurs.

    Bref, tout ça c’est bien joli mais à première vue une bonne partie n’est qu’un problème de déve­lop­peur frus­tré, pas un problème de langage.

    Ce qui me frustre moi c’est que des problèmes de langages il y en a plein, et que pous­ser des faux problèmes décré­di­bi­lise ceux qui essayent de corri­ger les problèmes réels.

  • Je veux chan­ger ça, et ça, et ça

    Je pense que je ne suis pas le seul à imagi­ner régu­liè­re­ment comment créer un nouveau langage ou modi­fier les exis­tants à ma conve­nance. Sans aller jusque là, en croi­sant ce qui se fait dans les diffé­rents langages, on trouve toujours des point inté­res­sants qu’on aime­rait voir copiés.

    Voilà donc quelques unes de mes frus­tra­tions, parce que les expri­mer permet de s’en débar­ras­ser un peu et de se concen­trer sur l’im­por­tant : ce qu’on fait avec le langage.

    Persis­tance du code en PHP

    Chaque requête web recharge entiè­re­ment l’ap­pli­ca­tif PHP. APC apporte une béquille indis­pen­sable mais ça reste au niveau de la béquille. Toute l’ini­tia­li­sa­tion est à refaire à chaque fois. Ça fonc­tionne, mais j’ai­me­rai vrai­ment un mode de PHP ou un frame­work web PHP qui permette de commen­cer direc­te­ment au trai­te­ment des requêtes sans avoir à tout refaire de zéro.

    Acces­seurs en PHP

    Toujours côté PHP j’at­tends depuis bien long­temps l’ap­pa­ri­tion d’ac­ces­seurs trans­pa­rents pour les attri­buts des objets. Ruby, Python et Javas­cript ont chacun leur façon de faire. Là il ne s’agit pas de repiquer une syntaxe au langage voisin mais bien de combler un manque.
    Sérieu­se­ment, je n’en peux plus de ces getX() et setX(). C’est encore plus pénible à l’uti­li­sa­tion qu’à la créa­tion.

    Espaces de noms

    Fut un temps je râlais beau­coup contre PHP mais ce dernier une bonne partie du retard qu’il avait. Mieux : Arrivé en dernier il s’est permis de parfois faire les choses plus intel­li­gem­ment.

    Dites, pourquoi n’ai-je pas d’es­paces de nom en Javas­cript ?

    Les « use » de PHP me manquent aussi en Ruby. Ils présentent une solu­tion élégante et pour donner des noms courts en local à des classes qui viennent d’autres espaces de noms, mais ils permettent aussi les alias pour chan­ger faci­le­ment une implé­men­ta­tion par une autre sans impac­ter le code.

    Pendant qu’on y est, pourquoi pas d’auto-char­ge­ment en Ruby ? Si je charge X::Y::Z, j’ai­me­rai bien que le langage se charge tout seul d’al­ler cher­cher le fichier X/Y/Z.rb. Ça fonc­tionne dans quasi­ment tous les autres langages mais Ruby conti­nue de faire du spaghetti d’in­clu­sion manuelle de fichiers.

    Blocs et ferme­tures lexi­cales

    Les blocs sont *la* fonc­tion­na­lité qui me fait utili­ser Ruby. On peut certes faire beau­coup de choses simi­laires avec des fonc­tions anonymes en Javas­cript ou en PHP mais c’est juste moins élégant (et ça compte beau­coup pour se sentir à l’aise).

    Par contre, sérieu­se­ment, la récep­tion des para­mètres dans les blocs est vrai­ment peu lisible. Le choix de la barre verti­cale comme déli­mi­teur est juste illi­sible.

    Le pire arrive avec les ferme­tures lexi­cales. Ruby laisse bien trop faci­le­ment utili­ser par erreur une variable venant de la portée parente. La syntaxe pour forcer une variable comme locale ajoute encore plus au côté non lisible. |x, y=3; z| ? sérieu­se­ment ?

    À côté de ça PHP et Python proposent des variables en lecture seule, ce qui limite la casse. PHP impose même de décla­rer expli­ci­te­ment les variables à impor­ter de la portée parente au lieu de décla­rer les variables locales. Diffi­cile à imagi­ner en monde Ruby mais assez confor­table au final.

    Et vous ? qu’est-ce que vous chan­ge­riez en premier ?

  • Évolu­tion de PHP – acces­seurs

    Il y a matière à se réjouir : Le déve­lop­pe­ment et l’évo­lu­tion du langage PHP a repris. Nous avons eu les fonc­tions anonymes, les espaces de nom, et quelques nouveau­tés bien­ve­nues, souvent atten­dues de trèèèèès longue date.

    Bref, ça bouge, bien. Nous avons  cepen­dant encore deux courants très oppo­sés au niveau du langage : L’un qui souhaite le garder simple et « comme il est », avec souvent un histo­rique quick’n dirty, et qui au final freine quasi­ment toutes les évolu­tions. L’autre qui souhaite le voir profon­dé­ment changé, et reprendre les bonnes idées des autres langages, au risque de trop vouloir copier ces autres langages.

    Si je devais cari­ca­tu­rer je dirai qu’une majo­rité des déve­lop­peurs de PHP (surtout les histo­riques) sont ceux qui freinent, et qu’une majo­rité des utili­sa­teurs actifs de PHP sont ceux qui poussent. Si ça bouge depuis PHP 5.3, c’est que l’ex­cès du « on ne touche rien » a provoqué un trop grand ras-le-bol, et les déve­lop­peurs de PHP ont été forcés de mettre de l’eau dans leur vin.

    Malheu­reu­se­ment les deux courants existent toujours et rien n’a été tran­ché. On le voit très bien sur la RFC concer­nant les acces­seurs : Une bonne partie des « contre » sont ceux que je quali­fie de « déve­lop­peurs histo­riques du langage », et une partie des « pour » sont ceux que je quali­fie de « utili­sa­teurs actifs dans le langage ».

    Il est plus que temps de déci­der où l’on va, sinon nous allons conti­nuer à avoir un Fran­ken­stein.