Une interface n'est pas un type, TypeScript permet d'ailleurs également de déplacer des types personnalisés.
Tu pourrais être un peu moins agressif, d'autant plus que tes interventions n'apportent pas grand-chose à la question posée.
Version imprimable
Une interface n'est pas un type, TypeScript permet d'ailleurs également de déplacer des types personnalisés.
Tu pourrais être un peu moins agressif, d'autant plus que tes interventions n'apportent pas grand-chose à la question posée.
Documentation TypeScript sur les interfaces, 1er paragraphe :Citation:
Envoyé par Sodium
One of TypeScript’s core principles is that type checking focuses on the shape that values have. This is sometimes called “duck typing” or “structural subtyping”. In TypeScript, interfaces fill the role of naming these types, and are a powerful way of defining contracts within your code as well as contracts with code outside of your project.
Désolé je réponds vite et je vais à l'essentiel parce que j'ai peu de temps et que je ne peux pas laisser des inepties sans réponses sur ce forum quand j'en lis parce qu'il y a des gens qui nous lisent.Citation:
Envoyé par Sodium
Du coup c'est possible que la forme n'y soit pas je m'en excuse.
A la question initiale pas littéralement ça mériterait un autre sujet mais c'est quand même très lié.Citation:
Envoyé par Sodium
Un défaut courant des devs Java / .NET c'est d'aller vers TS en pensant se retrouver dans le même style de langage. C'est une erreur. Une vraie erreur de débutant. J'ai vu des devs Java se lancer dans Angular sans lire la doc TypeScript en partant du principe que c'était du TS donc ce qui était vrai en Java était vrai en TS. Je crains également que beaucoup de décideurs qui choisissent des stacks J2EE / Angular ou .NET / Angular aillent vers ce genre de stack avec des profils fullstack en pensant faire des économies, notamment de formation sur la partie JS / TS. C'est une erreur et ça peut couter cher en maintenance à l'arrivée.
En pratique, je me sers effectivement principalement des interfaces généralement pour valider des structures de données JSON... ça n'empêche pas qu'elles ont les même fonctionnalités que dans d'autres langages.
Quant à confondre TypeScript et Java... ça me paraît tout de même assez évident que deux langages n'auront jamais exactement la même syntaxe et logique, je ne vois pas un développeur ayant un minimum d'expérience se dire qu'il va pouvoir installer TypeScript et coder du Java tranquillou.
8OCitation:
Envoyé par Sodium
Tu te sers des interfaces pour valider des données au runtime ?
Ben non puisqu'elles n'existent pas au runtime. Ça ne sert qu'au développeur à la phase de transpilation pour lui dire qu'il essaie de faire rentrer un rond dans un espace prévu pour un carré.Citation:
Envoyé par Sodium
C'est pas qu'ils n'ont pas exactement la même syntaxe et logique, c'est qu'ils n'ont pas du tout la même syntaxe et logique.Citation:
Envoyé par Sodium
Et je t'assure qu'il y a une quantité pas croyable de devs dits "fullstack" qui pensent pouvoir se passer de lire la doc TS sous prétexte qu'ils font du Java ou du .NET.
Vu que ce n'est pas moi qui gère le backend c'est bien pratique si le mec en charge oublie de me dire qu'il a changé sa structure de données en phase dev.Citation:
Envoyé par Marco46
Puis c'est pratique aussi pour faire le mappage entre les noms de champs tout pourris de notre bdd du genre srgptg et les miens qui veulent dire des trucs :aie:
Mais l'interface n'existe pas au runtime.
Si ton interface c'est par exemple :
Code:
2
3
4
5
Et que ton JSON contient uniquement prop1, tu n'auras aucune erreur sur prop2 sauf si tu testes manuellement le truc.
C'est uniquement pour déclarer explicitement les contrats de tes paramètres d'entrée et tes retours de fonctions. C'est tout.
c'est bien beau de mettre en gras et surligner tout en essayant de convaincre mais au final on a une syntaxe proche à 80% et une logique d'abstraction equivalente.Citation:
Envoyé par Marco46
c'est un autre pb .Citation:
Envoyé par Marco46
quand j'achete un aspirateur , je ne regarde pas forcément la notice. çà doit marcher comme tous les autres aspirateurs. puis au final c'est bien plus intuitif de jouer avec et regarder le manuel après.
TS fait de l'objet assez proche de Java avec les meme concepts.
On peut etre en désaccord sur les buts recherchés de chacun mais c'est un autre débat.
Ah bah carrément pas. Typage structurel d'un côté, nominal de l'autre, sans aucune info de typage statique au runtime pour TS le contraire pour Java, fonctions first-class pour TS, les classes comme brique de base pour Java, ...Citation:
Envoyé par Engiwip
Ça fait déjà de très très grosses différences.
(EDIT :Et je parle même pas de la gestion de l'asynchrone qui est catastrophique avec Java, on pourrait parler aussi de l'event loop JS que l'on soit browser side ou server side contre la gestion en threads côté Java, fin bref ... Les différences sont très nombreuses et fondamentales.)
J'ai bien compris que tu voulais utiliser TypeScript sans lire la notice. C'est bien le problème ;)Citation:
Envoyé par Engiwip
En pratique, le nez dedans ce n'est pas si important. vraiment. je dis pas de faire un projet opengl avec non plus hein?Citation:
Envoyé par Marco46
on s'egare de la discussion , on ne compare pas Node avec J2ee....Citation:
Envoyé par Marco46
la notice quelle notice ? :mouarf:Citation:
Envoyé par Marco46