Catégorie : Python

  • 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 ?