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 !

Quelles sont les nouvelles fonctionnalités qui pourraient débarquer dans JavaScript en 2019 ?
Un tour d'horizon des candidats pour ES2019

Le , par Michael Guilloux

577PARTAGES

13  0 
Vous avez lu gratuitement 153 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
https://www.developpez.com
Le 23/01/2019 à 7:00
On repart déjà pour 4 pages de Sodium VS JavaScript ou on attend trolldi?
7  0 
Avatar de grunk
Modérateur https://www.developpez.com
Le 23/01/2019 à 9:41
Citation Envoyé par Beginner. Voir le message
Oui le mot clé "private" serait plus clair/lisible pour l'utilisateur mais je crois que c'est plus difficile à prendre en compte coté outils d'assistance...

Par exemple un IDE lors d'une auto-complétion pourrait facilement filtrer les suggestions (proposées par les outils actuels) de sorte à ne proposer que ce qui n'est pas privé (que ce qui ne commence pas par un "#" ou un "_" ou autre selon la convention adoptée), il n'y aurait pas besoin par exemple d'avoir un tokeniser/parser qui tienne compte du mot clé "private"...
N'importe quel ide sait déjà gérer les mots clé de visibilité dans tous les autre langages.
Cela à encore moins de sens qu'il utilise le mot clé static.
Quitte à vouloir faire originale , autant être consistent dans les idées à la con
Code : Sélectionner tout
1
2
#variable_privee;
@variable_static;
Typescript propose plein de chose intéressante , il ferait bien de s'en inspirer un peu.

Citation Envoyé par psancho Voir le message
je trouve, au contraire de mes camarades, la notation # plutôt intelligente: avec un seul caractère, on identifie tout de suite la portée de la variable où qu'elle soit utilisée. Nul besoin de convention d'écriture. D'autre part, ça rend la déclaration moins verbeuse.
Perso je préfère écrire private une fois que devoir me traîner un # sur toutes les utilisations de la variable , ce qui, à mon sens , est autrement plus lourd.

Les conventions d'écriture sur les visibilités ou les types c'était bien y'a 15 ans quand les ide n'était pas au niveau où il sont maintenant. Ça fait un paquet d'années que je préfixe plus mes variables et ça ne m'a jamais poser le moindre problème , justement parce que les ide sont capables de gérer tout ça correctement à ma place.
4  1 
Avatar de grunk
Modérateur https://www.developpez.com
Le 25/01/2019 à 12:00
Pour continuer sur les raisons du pourquoi du # : https://github.com/tc39/proposal-cla..._SYNTAX_FAQ.md

Moralité , je suis pas prêt de laisser tomber typescript pour me remettre à du vanilla js ...

J'ai quand même l'impression qu'on essai de faire avancer JS dans le bon sens , mais que c'est tout simplement pas prévu pour et que du coup on en vient à ce genre de truc qui ressemble plus à du bricolage qu' à autre chose (à mon sens)
2  0 
Avatar de Beginner.
Membre expert https://www.developpez.com
Le 23/01/2019 à 8:53
Citation Envoyé par Sodium Voir le message
En effet... il y a toujours eu chez JavaScript cette politique du comment faire simple quand on peut avoir une syntaxe bizarre difficilement compréhensible pour une personne extérieure au langage.
Oui le mot clé "private" serait plus clair/lisible pour l'utilisateur mais je crois que c'est plus difficile à prendre en compte coté outils d'assistance...

Par exemple un IDE lors d'une auto-complétion pourrait facilement filtrer les suggestions (proposées par les outils actuels) de sorte à ne proposer que ce qui n'est pas privé (que ce qui ne commence pas par un "#" ou un "_" ou autre selon la convention adoptée), il n'y aurait pas besoin par exemple d'avoir un tokeniser/parser qui tienne compte du mot clé "private"...
0  0 
Avatar de psancho
Nouveau membre du Club https://www.developpez.com
Le 23/01/2019 à 9:22
je trouve, au contraire de mes camarades, la notation # plutôt intelligente: avec un seul caractère, on identifie tout de suite la portée de la variable où qu'elle soit utilisée. Nul besoin de convention d'écriture. D'autre part, ça rend la déclaration moins verbeuse.
1  1 
Avatar de grunk
Modérateur https://www.developpez.com
Le 23/01/2019 à 10:59
Citation Envoyé par Beginner. Voir le message
Comme tu dis toi-même : "dans tous les autre langages" mais là on parle de JS et les outils pour JS ne prennent pas (encore) en compte le mot clé "private"...
Des ide comme webstorm ou vscode le gère déjà avec typescript. Ils devrait être capable de s'en sortir avec du JS

Faire évoluer ces outils est quand même plus difficile que de faire ce que je disais à savoir : Lors d'une auto-complétion un IDE pourrait facilement filtrer les suggestions (proposées par les outils actuels) de sorte à ne proposer que ce qui n'est pas privé (que ce qui ne commence pas par un "#" ou un "_" ou autre selon la convention adoptée).
Pour faire se filtrage , il va falloir dans tous les cas une màj de l'ide.
Et puis comme il vont supporter le mot clé static , il pourrait très bien supporter private en même temps.

Y'a peut être une vraie bonne raison derrière ce choix , mais faciliter la vie aux ide n'en est pas une.
1  1 
Avatar de Beginner.
Membre expert https://www.developpez.com
Le 23/01/2019 à 11:03
Citation Envoyé par Sodium Voir le message
Eh bien il faut faire évoluer les outils plutôt que de faire régresser le langage...
Ce n'est pas si simple... Qui va le faire ? Et est-ce que cela sera gratuit et open source ?

Bon je pense que ceux qui travaillent sur TypeScript le feront peut-être, les outils pour TS fonctionnent aussi pour JS, j'ai d'ailleurs testé tsserver mais franchement ce n'est pas facile à utiliser car la documentation est rare, j'ai dû regarder l'intégration faite par d'autres pour essayer de comprendre...

Sur certains points je trouve que tern est plus efficace que tsserver mais hélas tern n'est plus maintenu par son auteur mais peut-être qu'il fera quand même évoluer le parseur Acorn (dont il est aussi l'auteur)...
0  0 
Avatar de Beginner.
Membre expert https://www.developpez.com
Le 23/01/2019 à 11:16
ah nos message se sont croisés..

Citation Envoyé par grunk Voir le message

Pour faire se filtrage , il va falloir dans tous les cas une màj de l'ide.
Mais ce filtrage est facile à faire, ce n'est pas difficile d'analyser toutes les suggestions pour écarter toutes celles qui commencent par un caractère donné.

Par contre faire évoluer un parser (et les outils qui l'utiliseront) ce n'est pas à la porté de tout le monde...

Citation Envoyé par grunk Voir le message
Et puis comme il vont supporter le mot clé static , il pourrait très bien supporter private en même temps.
"static" existe déjà, non ?

Citation Envoyé par grunk Voir le message
Des ide comme webstorm ou vscode le gère déjà avec typescript. Ils devrait être capable de s'en sortir avec du JS
Oui c'est vrai, comme je disais aussi je pense qu'ils le feront et en plus on peut intégrer ces outils ailleurs, d'ailleurs c'est déjà le cas même en Java avec Eclipse par exemple...
0  0 
Avatar de Pyramidev
Expert éminent https://www.developpez.com
Le 23/01/2019 à 11:55
Citation Envoyé par Michael Guilloux Voir le message
Au cours des dernières années, JavaScript a évolué à un rythme soutenu avec de nouvelles fonctionnalités de langage apportées à la spécification ECMAScript suivant un processus normalisé avec 5 étapes de maturité : idée (étape 0), proposition formelle (étape 1), brouillon (étape 2), candidat (étape 3) et approuvé (étape 4).
Pour ceux que ça intéresse, voici la liste des propositions d'ajouts de fonctionnalités : ECMAScript proposals.

Remarque : parmi les fonctionnalités qui sont encore en stage 2, il y a déjà un support pour les décorateurs dans Babel et dans TypeScript (depuis TypeScript 1.5).
Rq : je n'ai pas encore testé.
0  0 
Avatar de grunk
Modérateur https://www.developpez.com
Le 23/01/2019 à 13:57
J'ai pas tout lu mais à priori l'utilisation de private est problématique car

si je déclare un champs :
Code : Sélectionner tout
private toto;
et que plus loin je fait

Code : Sélectionner tout
this.toto = 0;
Je ne ferais pas référence à mon membre privé mais à un membre toto publique qui serait implicitement crée ... Ce qui est clairement pas idéal.

il faudrait alors plutôt écrire quelque chose comme
Code : Sélectionner tout
private.toto = 0
Ce que je trouve toujours plus élégant que this.#toto = 0 mais ça reste personnel.

Si j'ai bien compris c'est le genre de truc qui renforce tout le bien que je pense de JS

https://github.com/tc39/proposal-pri...hods/issues/28
0  0