IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Claude Michel

485PARTAGES

10  0 
Vous avez lu gratuitement 131 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de SylvainPV
Rédacteur/Modérateur https://www.developpez.com
Le 20/07/2017 à 17:55
@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
2  0 
Avatar de TiranusKBX
Expert confirmé https://www.developpez.com
Le 13/07/2017 à 14:49
je ne sait pas pour vous mais ça sent le C#
1  0 
Avatar de psychadelic
Expert confirmé https://www.developpez.com
Le 15/07/2017 à 13:09
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.
1  0 
Avatar de sitexw
Membre régulier https://www.developpez.com
Le 13/07/2017 à 13:34
0  0 
Avatar de Zefling
Expert confirmé https://www.developpez.com
Le 13/07/2017 à 17:01
Citation Envoyé par TiranusKBX Voir le message
je ne sait pas pour vous mais ça sent le C#
Je connais pas vraiment C#, mais j'aurais plus dit TypeScript
0  0 
Avatar de TiranusKBX
Expert confirmé https://www.developpez.com
Le 15/07/2017 à 3:47
tu doit mettre le mot await pour les appels asynchrones(déclarées avec le mot async) comme dans la spécification EcmaScript 2017
0  0 
Avatar de psychadelic
Expert confirmé https://www.developpez.com
Le 15/07/2017 à 2:15
?? Que je sache, je ne crois pas que C# fonctionne nativement en asynchrone ??

en tout cas pas comme en JavaScript.
exemple ;
Code : Sélectionner tout
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() )...
0  1 
Avatar de psychadelic
Expert confirmé https://www.developpez.com
Le 18/07/2017 à 0:24
J'y reviens...

Citation Envoyé par TiranusKBX Voir le message
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.
0  3