ECMAScript 2017 : Ecma International annonce les nouvelles mises à jour de ses spécifications,

Pour les langages de script

Le 2017-07-12 23:56:18, par Claude Michel, Membre émérite

Ecma international, le comité international responsable de l'ensemble des normes des langages de script, a annoncé ses nouvelles mises à jour ECMAScript 2017 (ES8). Cette publication s’inscrit dans le cadre de la décision de l’Ecma de sortir des mises à jour plus petites, mais plus fréquentes pour faciliter leur intégration dans les différents navigateurs. Ainsi l’Ecma a publié ECMAScript 2015 en 2015 puis ECMAScript 2016 en 2016.

L’ECMAScript 2017 a apporté de nouvelles caractéristiques portant sur différents concepts des scripts et de JavaScript en particulier. Il convient de noter que nous avons six nouvelles caractéristiques majeures que nous allons passer en revue.

Les fonctions asynchrones

La combinaison des promises (promesses en français) et les générateurs permet de travailler avec un code asynchrone dans ECMAScript et ainsi abandonner les callbacks enchaînés

Code javascript :

1
2
3
4
5
6
7
8
9
10
async function myFunction(id) { 
  try { 
    const val1 = await myAsyncFunc1(id); 
    const val2 = await myAsyncFunc2(val1); 
    console.log(`Woho! The output of async call is: ${val2}`); 
  } 
  catch (err) { 
    console.log('Uuuups!', err); 
  } 
}

Shared memory and atomics

Pour allouer ou partager de la mémoire entre plusieurs agents :

Code javascript :

sab = new SharedArrayBuffer(1024);  // 1KiB shared memory

L’objet global Atomics propose un certain nombre d’opérations sous forme de méthodes statiques pour servir à plusieurs fins en relation.

Object.values and Object.entries

Les méthodes entries() et values() permettent de retourner un objet de paires attribut/valeur. Ce qui permettrait de se passer d’autres bibliothèques JavaScript comme JQuery par exemple.

Code javascript :

1
2
3
4
5
6
const myObject = { 
  name: 'Paweł', 
  age: 29 
}; 
  
Object.entries(myObject);

String padding

Une sorte de formatage de chaînes de caractères au sein du script. En utilisant les méthodes padStart() ou padEnd(), on peut ajouter des espaces ou caractères spécifiques, selon les paramètres, au début ou à la fin d’une chaîne de caractères.

Code :

1
2
3
4
5
'machaine'.padStart(20); 
// "        machaine" 
 
'machaine'.padEnd(20, '*'); 
// "machaine********"

Object.getOwnPropertyDescriptors()

En lui passant un objet en paramètre, elle retourne un nouvel objet dont les propriétés ont les mêmes clés que les propriétés de l’objet cloné, mais ont pour valeurs les descripteurs de ces propriétés :

Code javascript :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
const obj = { 
    [Symbol('foo')]: 123, 
    get bar() { return 'abc' }, 
}; 
console.log(Object.getOwnPropertyDescriptors(obj)); 
  
// Output: 
// { [Symbol('foo')]: 
//    { value: 123, 
//      writable: true, 
//      enumerable: true, 
//      configurable: true }, 
//   bar: 
//    { get: [Function: bar], 
//      set: undefined, 
//      enumerable: true, 
//      configurable: true } }

Trailing commas

Pour autoriser les virgules avec retour à la ligne dans la liste des paramètres des fonctions et dans les objets littéraux.

Code javascript :

1
2
3
4
5
6
7
8
9
let obj = { 
    prop1: 'val1', 
    prop2: 'val2', 
}; 
  
function myFunction( 
    param1, 
    param2, 
) {}

Source : ECMAScript

Et vous ?

Que pensez-vous de ses nouvelles mises à jour ?

Voir aussi

ECMAScript 2016 : des mises à jour plus petites et plus fréquentes pour l'ensemble de normes des langages de script

Discussion forum

8 commentaires

SylvainPV
Rédacteur/Modérateur

@Zefling: en même temps TypeScript est une surcouche de JavaScript donc c'est un peu normal qu'ils se ressemblent

@psychadelic: non, TiranusKBX a raison, await concerne uniquement les appels de fonctions asynchrones retournant une Promise. La plupart des fonctions JavaScript sont synchrones et heureusement

le 20/07/2017 à 17:55
TiranusKBX
Expert confirmé

je ne sait pas pour vous mais ça sent le C#

le 13/07/2017 à 14:49
psychadelic
Expert confirmé

mettre un simple await devant l'appel ne suffit pas, il faut aussi rajouter une promesse dans la fonction appelée, sinon le await ne sert à rien (et il prend "indéfini" comme réponse).

Et maintenant la 262 est devenue une EcmaScript 2018

Draft ECMA-262 / July 13, 2017
ECMAScript® 2018 Language Specification

=> https://tc39.github.io/ecma262
=> https://tc39.github.io/ecma262/#sec-...on-definitions

car la ECMA-262 est toujours au niveau d'un"draft" depuis au moins 2015, et aujourd'hui les spécifications seront pour 2018...

Les explications fournies dans la new sont vraiment tarabiscotées en faisant l'impasse sur l'importance d'avoir à placer une promesse dans la fonction appelée.
je préfère de loin celle de MDN
=> https://developer.mozilla.org/fr/doc...9rateurs/await

De toutes façon les promesses ne sont pas encore implémentées partout, et en attendant j'utilise jQuery quand l'asynchronicité du JavaScript pose problème dans le code (objets deferred )

ET ma question ne portait pas sur de la syntaxe, mais sur le fait qu'on puisse comparer un langage asynchrone comme JavaScript avec le C# qui ne l'est pas.

le 15/07/2017 à 13:09
sitexw
Membre régulier

le 13/07/2017 à 13:34
Zefling
Expert confirmé

Envoyé par TiranusKBX

je ne sait pas pour vous mais ça sent le C#

Je connais pas vraiment C#, mais j'aurais plus dit TypeScript

le 13/07/2017 à 17:01
TiranusKBX
Expert confirmé

tu doit mettre le mot await pour les appels asynchrones(déclarées avec le mot async) comme dans la spécification EcmaScript 2017

le 15/07/2017 à 3:47
psychadelic
Expert confirmé
?? Que je sache, je ne crois pas que C# fonctionne nativement en asynchrone ??

en tout cas pas comme en JavaScript.
exemple ;
Code :
```
1
2
var a = fonction_tres_lente();
var b = a+5;  /* plante, car cette ligne s'exécute avant que  fonction_tres_lente() ait renvoyé une valeur */
```
c'est une erreur fréquente que rencontrent les "débutants" en JavaScript (même s'ils l'écrivent en TypeScript).
et même si on utilise PureScript le JavaScript généré produira toujours cette même erreur.

Le truc des promesses en JavaScript, c'est fait justement pour maîtriser les enchaînements de code, ç’a n'a rien à voir avec une gestion du muti-tache telle qu'elle est faite dans la plupart des Langages.
Le seul autre langage à ma connaissance pouvant partager cette conception asynchrone c'est Clojure.

Ceci étant, c'est un peu normal que ECMA continue à faire son job sur la normalisation de ce langage.
Perso je trouve que l'utilisation de TypeScript simplifie pas mal les choses pour produire du JavaScript propre.

car il faut bien le reconnaître, au départ JavaScript était du bricolage, Brendan Eich lui même à demandé pardon, et "heureusement" l'arrivée de jQuery à certainement du éviter pas mal de suicides chez les codeurs.
D'ailleurs, cette gestion des promesses à un petit goût de jQuery (deferred.promise() )...
le 15/07/2017 à 2:15
psychadelic
Expert confirmé

J'y reviens...

Envoyé par TiranusKBX

tu doit mettre le mot await pour les appels asynchrones(déclarées avec le mot async) comme dans la spécification EcmaScript 2017

Désolé mais ce que tu a écrit est faux, en JavaScript les appels sont toujours asynchrones.

Ce n'est donc pas l'utilisation d'un await qui rendrait la fonction subitement asynchrone, avec ou sans elle l'est toujours.

JavaScript est un langage asynchrone et chaque fonction écrite est considérée comme un objet que les interpréteurs JavaScript exécuteront dans leur boucle d’événements sans se soucier de leur priorité.

L'utilisation du await, c'est justement pour prévenir que l'affectation d'appel doit attendre que le la fonction appelée soit achevée avant de passer aux instructions suivantes.
Et cette fonction appelée doit elle aussi obéir à ce protocole en renseignant une promesse que l'await consulte à chaque cycle de la boucle événementielle de l'interpréteur, pour vérifier s'il peut récupérer le résultat.

S'il la fonction appelée ne respecte pas cette syntaxe, alors la fonction await ne pourra pas vérifier que la fonction appelée se soit achevée ou non, et il prendra la valeur "undefined" à la place, sauf si par miracle la fonction ait pu répondre avant dans le temps de cycle d’exécution qui lui était allouée.

Ce qui au passage permet de voir qu'il y a un faussé entre les langages JavaScript et C#.

Comparer des langages en se basant uniquement sur leur syntaxe, c'est le meilleur moyen de mal programmer avec.

le 18/07/2017 à 0:24

Poster une réponse