Catégorie : Technique

Travailler avec ES2015 c’est quelques chan­ge­ments sur les décla­ra­tions des variables.

Premier chan­ge­ment : Les modules ES2015 sont impli­ci­te­ment en mode strict. Y utili­ser une variable non décla­rée provoque une erreur. Ce seul chan­ge­ment est une béné­dic­tion vu l’ubuesque compor­te­ment par défaut de Javas­cript. Il reste que ça ne chan­gera pas grand chose pour qui utili­sait déjà un outil d’ana­lyse de code (linter).

Pour décla­rer les variables nous avons aussi le nouveau mot clef let en complé­ment de l’an­cien var.  La portée est alors limi­tée au bloc de code parent le plus proche (if, while, func­tion, for…) au lieu d’être éten­due à toute la fonc­tion parente.

let a = 2;
for(let b=1; b<3; b++) {
  let a = 3;
  a = 4;
}
console.log(a); // 2 et non 4

Au début j’étais enthou­siasmé. J’ai trouvé excep­tion­nel de pouvoir travailler avec des variables jetables le temps de quelques lignes et j’ai pensé éviter de nombreuses réuti­li­sa­tions par erreur.

À l’usage c’est un ajout sympa mais pas si révo­lu­tion­naire. Si c’est pratique c’est surtout pour gérer les ferme­tures syntaxiques (closure) au sein des boucles. Le reste du temps ça n’a que peu d’in­fluence quand on a des fonc­tions de taille et de niveau d’im­bri­ca­tion raison­nables.

var fns = [ ];
for(var i=1; i<3; i++) {
  fns.push( function () { console.log(i); } );
}
var fn = fns[0];
fn(); // affichera 3 et non 1

//----

fns = [ ];
for(let j=1; j<3; j++) {
  fns.push( function () { console.log(j); } );
}
fn = fns[0];
fn(); // affichera 1

Je me demande si ça pour­rait être la portée par défaut dans un langage. Visi­ble­ment certains pensent que non mais je n’ai pas été convaincu par l’ar­gu­men­taire.

L’autre nouvel arrivé c’est const. Décla­rée ainsi la variable a la même portée qu’un let mais on ne peut pas y affec­ter une valeur diffé­rente.

Là aussi c’est pas mal d’en­thou­siasme. Une variable qui est modi­fiée sans aver­tis­se­ment par une ferme­ture lexi­cale ou un module tiers, ça fait parfois des dégâts.

Le problème c’est que ça ne protège pas vrai­ment de ça. Si on ne peut pas affec­ter de nouvelle valeur au même nom de variable, la valeur elle même n’est pas immuable. On peut toujours faire chan­ger d’état un objet ou modi­fier les éléments d’un tableau. Domma­ge…

const tab = [ ];
tab[3] = 4; // ne provoque pas d'erreur mais change `tab`

const obj = { 
  var priv = 2; 
  this.chg = function() { priv = 3; };
};
obj.chg(); // `obj` vient de changer d'état silencieusement

tab = [1, 2, 3]; // là par contre on génère une erreur.

Pour obte­nir une vraie sûreté il faut utili­ser des des struc­tures de données expli­ci­te­ment prévues pour. On ne peut plus utili­ser les raccour­cis habi­tuels { } ou [ ] et l’ins­tan­cia­tion devient bien plus verbeuse. Facile d’ou­blier par inat­ten­tion et par habi­tude.

import immutable from "immutable";
const map = Immutable.Map({a:1, b:2, c:3});
// map ne changera plus jamais de valeur

Le problème c’est que tous les modules tiers conti­nuent à utili­ser les struc­tures de données variables habi­tuelles. Malheu­reu­se­ment des modules tiers, vue la pauvreté de la biblio­thèque stan­dard de Nodejs, on en utilise des tonnes,  y compris pour des fonc­tions de base.

Pour se proté­ger vrai­ment des chan­ge­ments d’état il faudra non seule­ment utili­ser expli­ci­te­ment nos struc­tures de données immuables (aie), mais en plus faire régu­liè­re­ment des conver­sions quand on commu­nique avec des modules tiers (ouch).

Il y a tout lieu de penser qu’on finira par avoir des données variables et d’autres immuables, suivant d’où elles viennent et comment elles sont décla­rées. Il faudra réflé­chir à chaque utili­sa­tion, parfois remon­ter à la créa­tion de la donnée. Possible même que le compor­te­ment de const avec les struc­tures de données natives nous incite plus d’une fois à nous croire en sécu­rité alors que ce ne sera pas le cas.

Pour moi c’est le scéna­rio du pire. Non seule­ment on complexi­fie le code (plus verbeux) et la charge cogni­tive (savoir à chaque fois quel est le type de variable et le type de données), mais en plus on garde des risques.

Pour jouer à ça il aurait fallu que le langage s’as­sure que ce qu’on déclare comme tel soit réel­le­ment immuable, jusqu’en profon­deur. Je comprends très bien pourquoi ça aurait été diffi­cile voire impos­sible, mais du coup ce const m’a l’air d’une vraie fausse bonne idée. Domma­ge…

Pour autant je me prends quand même à utili­ser const pour les litté­raux. Ça ne coûte pas grand chose et ça fixe par écrit l’in­ten­tion que j’ai en tête. Même si je n’y suis pas obligé, je fais tout de même atten­tion à garder let quand j’uti­lise un tableau ou un objet natif. J’ai trop peur d’in­duire en erreur le prochain déve­lop­peur qui passe (d’au­tant que ce sera proba­ble­ment moi).

Je jette­rai peut-être de nouveau un œil à immu­table.js si une partie signi­fi­ca­tive des modules s’y conver­tit. Entre temps le ratio béné­fices/(risques+­dé­fauts) me parait assez faible.

---

Au delà de ces ques­tions de décla­ra­tions, j’en tire un avis plutôt néga­tif sur la propa­ga­tion des variables en Javas­cript. On fait des ferme­tures lexi­cales de partout et on ne maitrise pas bien les effets de bord. Pas éton­nant que les déve­lop­peurs cherchent à avoir des variables et des struc­tures de données immuables ! Si la propa­ga­tion des variables était plus saines au départ, ce besoin ne ferait pas surface ainsi.

var i = 1;
function hello10times() {
  for(i=1; i<10; i++) {
    console.log("hello ");
  }
}
hello10times();
// oups ! i a changé et vaut désormais 10

PHP est plus strict (ouch, dire ça me fait mal) : Les variables ne sont pas décla­rées mais ne sont jamais héri­tées d’un contexte parent sauf à le décla­rer expli­ci­te­ment, avec global pour les variables globales, ou use pour les ferme­tures lexi­cales. On peut toujours faire des effets de bord assez moche, mais on les voit venir assez faci­le­ment.

$i = 3;
$hello10times = function () {
  for (i=1; i<10; i++) {
    echo "hello ";
  }
}
// $i vaut toujours 3

$hello10times = function () use ($i) {
 for (i=1; i<10; i++) {
 echo "hello ";
 }
}
// $i vaut 10 mais là c'est forcément intentionnel

La visi­bi­lité des variables de Python est plus proche de ce que fait Javas­cript mais, sauf à le décla­rer expli­ci­te­ment, si on utilise une variable d’un contexte parent, c’est en lecture seule. On garde des effets de bord, mais c’est déjà plus limité (bon, en échange savoir si la variable utili­sée est locale ou héri­tée n’est pas toujours super expli­cite).

---

D’ailleurs, quitte à parler d’ex­pli­cite, je trouve dommage d’avoir à décla­rer mes variables en Javas­cript. Il n’y a pas vrai­ment le choix vu l’his­to­rique du langage mais ça reste agaçant vue la faible valeur ajou­tée de la chose, surtout quand je vois avec Crys­tal que même un langage à typage statique peut s’en passer.

Si j’avais à créer un langage de zéro je pense que j’ap­pré­cie­rais de ne pas avoir à décla­rer mes variables, éven­tuel­le­ment leur donner la portée par défaut de let, mais avec la décla­ra­tion expli­cite de PHP pour les ferme­tures lexi­cales (avec peut-être une excep­tion pour les petites fonc­tions anonymes d’une unique ligne/expres­sion).

L’idée de const me plait beau­coup, mais unique­ment si le langage se révèle capable de réel­le­ment rendre la donnée tota­le­ment immuable, et ça en profon­deur. À minima le freeze de Ruby serait une demie-solu­tion (une demie seule­ment parce qu’il faut penser à faire un freeze récur­sif sur un clone de tous les objets avant leur affec­ta­tion par const, ce qui est assez pénible). Celui de Javas­cript ne me semble pas effi­cace pour bloquer les chan­ge­ments d’état d’objets qui contiennent des proprié­tés privées (implé­men­tées via des ferme­tures syntaxiques).

Tiens, ça pour­rait même être inté­gré au langage : si l’af­fec­ta­tion se fait avec := plutôt qu’a­vec =, alors ni la variable se voit affec­ter une copie immuable de la donnée, sans possi­bi­lité de modi­fi­ca­tion ou ré-affec­ta­tion.

Si vous déve­lop­pez le nouveau langage de demain, vous avez désor­mais mon cahier des charges :-)

Après la mise en place, il est peut-être temps de faire un premier script. J’ai tenté un petit script que j’ai fait la veille en ruby : lister toutes les images dans une hiérar­chie de réper­toires et faire un gros fichier Json qui réca­pi­tule les diffé­rentes tailles.

Faire un petit fichier outil CLI à l’aide de comman­der.js : un call­back. Lister les fichiers d’un réper­toire : un call­back. Lire les exif : un call­back. Écrire dans un fichier JSON : un call­back.

Bon, lire et écrire peuvent se faire en synchrone sans call­back – et dans mon cas précis ça ne chan­ge­rait proba­ble­ment rien – mais je suis là aussi pour apprendre comment faire pour plus tard dans cet écosys­tème.

Une hiérar­chie de quatre fonc­tions de rappel pour ce qui m’a pris 5 à 10 lignes tout mouillé en Ruby, ça me fait mal. J’avoue, je suis presque surpris que la trans­for­ma­tion en JSON ne me demande pas un call­back.

Me voici en plein call­back hell. Le problème est connu. J’ai bête­ment pensé qu’on me donne­rait une solu­tion rapi­de­ment, un outil ou un usage à suivre.

On me pointe vers les promesses ES2015 mais l’API Node et tous les modules en ligne conti­nuent à utili­ser des call­back. Sérieu­se­ment, personne n’a cher­ché à présen­ter l’API Node direc­te­ment en promesses ?

C’est donc à moi de trans­for­mer chaque méthode ou chaque module pour qu’il utilise des promesses. Promi­sify semble être la baguette magique pour ça. À partir de là il suffit de conver­tir chaque module pour enchaî­ner des promesses (atten­tion aux écueils).

Fran­che­ment ça reste assez moche. Des gens biens me pointent vers les systèmes à base de géné­ra­teurs (je recom­mande la lecture de ce lien) et le module co. Le code résul­tant est déjà bien plus lisible malgré les arti­fices.

On me rappelle alors les async / await (là aussi, je recom­mande la lecture). Je crois que c’est seule­ment main­te­nant, après cette explo­ra­tion, que je comprends l’in­té­rêt et le fonc­tion­ne­ment. Parfait, si ce n’est qu’il faut choi­sir presque au hasard entre trois plugins diffé­rents pour ajou­ter la fonc­tion­na­lité à Babel.

Atten­tion, ce n’est pas magique. Il faut se rappe­ler que ce n’est qu’une surcouche aux promesses, et il y a quelques écueils (lien indis­pen­sable si vous comp­tez utili­ser async/await) à bien connaitre là ici aussi, entre autres pour ne pas perdre les excep­tions dans un trou noir.

Je me retrouve avec un code qui a l’air rela­ti­ve­ment élégant mais la réalité me rattrape : Visi­ble­ment quasi aucun code en produc­tion ne fonc­tionne ainsi. Une majo­rité des gens utilisent encore des call­backs, les autres se sont conten­tés des promesses. Est-ce une bonne idée de déjà viser les async/await ?

---

Il reste aussi que j’ai l’im­pres­sion de retrou­ver le mode multi-tâche coopé­ra­tif de Micro­soft Windows 3.1 en moins bien inté­gré. Je ne vois aucune raison pour que la biblio­thèque stan­dard m’im­pose des call­backs, des promesses ou des async/await à tout bout de champ plutôt que de gérer ça en interne.

L’OS sait déjà passer à un autre proces­sus quand mon programme est en attente d’une i/o. Si la machine virtuelle du langage veut gérer plusieurs fils d’exé­cu­tion en interne pour opti­mi­ser le proces­seur, qu’elle le gère elle-même via l’API mise à dispo­si­tion. C’est à elle d’iden­ti­fier que je veux ouvrir un fichier et de savoir qu’elle peut favo­ri­ser un autre fil d’exé­cu­tion en atten­dant que le disque me remonte la donnée. Je trouve ahuris­sant que ces méca­nismes débordent sur mon code et le complexi­fient ainsi.

Oui, les promesses ne servent pas qu’à gérer la lenteur des i/o et faire coopé­rer les diffé­rents fils d’exé­cu­tions de la machine virtuelle V8 mais c’est quand même pour ça qu’on me les impose partout dans l’API de Node.js. Ça en devient même un style de program­ma­tion et les modules proposent des call­backs partout et pour tout (à vue de nez, y compris là où ça n’a pas vrai­ment de sens, à mon humble avis par mime­tisme).

Promesses, async, call­backs… J’adore tous ces concepts, mais quand j’en ai besoin moi, pas pour compen­ser les choix d’ar­chi­tec­ture du moteur sous-jacent.

Javas­cript a énor­mé­ment évolué, dans le bon sens. Côté syntaxe ES2015 et suivant donnent un résul­tat qui m’at­tire beau­coup. Le fonc­tion­ne­ment et l’API de Node.js me semblent pour l’ins­tant gâcher tout ce résul­tat. Un beau langage avec un boulet aux pieds.