Discussion :

[Marco46]

voila pourquoi j'aime typescript...
et swagger avec des services correctement typés

Moi aussi j'adore TypeScript, mais pour ce problème là qui est de détecter au runtime si une variable est une promesse il ne sert absolument à rien out of the box.

TypeScript n'existe pas au runtime donc si tu veux faire la même chose avec, il te faudra écrire un type guard ce qui revient à écrire le même code (à peu de choses près) que celui du package is-promise.

[Sodium]

Mais peut-être qu'à la compilation JS il ajoute justement ces tests, à vérifier.

[Sodium]

Je tiens également à souligner que les downvotes de personnes juste parce qu'elles ne m'aiment pas ça me fait toujours plaisir, je n'ai pas envie d'être d'accord avec certaines personnes

[LeBressaud]

La différence est que C++ est un vrai langage. En JavaScript il faut en permanence faire des abstractions compliquées pour des choses simples. Si JavaScript avait une méthode pour faire cela, on n'aurait besoin ni d'une dépendance, ni de faire sa propre implémentation.

Se plaindre de la bibliothèque standard de javascript en prenant celle du C++ comme exemple faut quand même le faire...

[Invité]

Se plaindre de la bibliothèque standard de javascript en prenant celle du C++ comme exemple faut quand même le faire...

Peux-tu développer ?

[Marco46]

Mais peut-être qu'à la compilation JS il ajoute justement ces tests, à vérifier.

C'est la différence entre nous deux : J'ai vérifié.

[Invité]

Le précédent problème du même genre datant d'il y a quatre ans.
Donc ça fonctionne plutôt bien en fait.

Perso, quand un problème qui s'est déjà produit se produit à nouveau, je n'appelle pas ça "fonctionner plutôt bien". Et j'espère sincèrement que les gens qui programment les freins de voitures ou les appareils médicaux pensent comme moi...

[dfiad77pro]

Moi aussi j'adore TypeScript, mais pour ce problème là qui est de détecter au runtime si une variable est une promesse il ne sert absolument à rien out of the box.

TypeScript n'existe pas au runtime donc si tu veux faire la même chose avec, il te faudra écrire un type guard ce qui revient à écrire le même code (à peu de choses près) que celui du package is-promise.

Après ça c'est un peu pareil en C#/Java, etc, si ton Api renvoi de données avec une structure aléatoire, c'est chiant
rajouter un tas de test au runtime ça à un coût, donc moi je suis plutôt pour automatiser des tests dans ce cas

[Marco46]

Perso, quand un problème qui s'est déjà produit se produit à nouveau, je n'appelle pas ça "fonctionner plutôt bien".

Ce n'est pas du tout le même problème qu'il y a 4 ans.

Il y a 4 ans c'était le mainteneur d'une dépendance utilisée dans un très grand nombre de dépendances qui avait été supprimée du registre.

Ici c'est une dépendance existante qui n'est pas compatible avec une version beta de la plateforme. Le problème n'existe donc que si tu utilises le package (non patché) avec la dernière version beta de node.

[Phago]

Zéro pertinence de l'intervention.

Tu as pas vraiment le niveau pour te permettre de dire un truc si violent. Tu as le droit de dire que le fait qu'il ne soit pas à l'aise en publique ne te donne pas envie de regarder la vidéo mais lâcher un "c'est juste pas possible" .. ? Le mec est un génie, il révolutionne le web et il est pas à l'aise en publique donc on l'ignore ?

Tes commentaires n'ont aucun intérêt donc on a les réponses qu'on mérite

[Sodium]

Ne pas savoir parler en public c'est une chose. Faire un Powerpoint et en lire le contenu devant le public par contre c'est l'erreur de débutant numéro un à bannir et largement admise. D'ailleurs la meilleure preuve c'est que dès qu'il sort de son rail de points à citer il est déjà beaucoup plus à l'aise.

[admadama]

Moi aussi j'adore TypeScript, mais pour ce problème là qui est de détecter au runtime si une variable est une promesse il ne sert absolument à rien out of the box.

TypeScript n'existe pas au runtime donc si tu veux faire la même chose avec, il te faudra écrire un type guard ce qui revient à écrire le même code (à peu de choses près) que celui du package is-promise.

Cette histoire de paramètre "souple" est pour moi est un défaut de conception majeur. Dans ce cas là autant créer de constructeurs additionnels : .fromString(), .fromPromise() ... et ainsi s'assurer d'une vérification statique.

Un exemple en Dart :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class Player {  Player(String name, int color) {
    this._color = color;
    this._name = name;
  }
 
 
  Player.fromPlayer(Player another) {
    this._color = another.getColor();
    this._name = another.getName();
  }  
}
 
 
new Player.fromPlayer(playerOne);

[Sodium]

La "souplesse" ça n'a jamais rien servi à rien. Si une fonction a besoin de traiter des paramètres de types variables, c'est qu'elle est mal foutue.

[frfancha]

Après ça c'est un peu pareil en C#/Java, etc, si ton Api renvoi de données avec une structure aléatoire, c'est chiant
rajouter un tas de test au runtime ça à un coût, donc moi je suis plutôt pour automatiser des tests dans ce cas

Sauf que c'est pas du tout de cela dont on parle.
On parle de l'overloading du type des paramètres.