il est très simple d'écrire une signature de fonction aussi générique soit-elle. Au lieu d'utiliser Int ou String, tu utilises a par exemple
Ce n'est pas parce que c'est simple à écrire que c'est simple à remarquer (il y a par exemple le cas fréquent d'une fonction sur les chaînes de caractères qui s'appliquent souvent aussi à des tableaux, mais il y a énormément de cas moins évidents).
Haskell est un des langages avec la meilleure inférence de types, c'est dommage de faire le boulot du compilateur à la main et en moins bien.
Il se trouve qu'en Haskell ou en Elm (les deux langages en FP que j'ai pu pratiquer jusqu'à présent), on écrit tout de même les signatures des fonctions et donc les types des arguments
En Haskell (je ne connais pas Elm) ce n'est pas nécessaire. Tu as d'ailleurs intérêt à ne pas le faire car cela te permet de te rendre compte que ta fonction est plus générique que ce que tu pensais en l'écrivant.
principalement parce que le code est destiné à être lu par des êtres humains, qui n'ont pas toujours le temps ou l'envie d'analyser le corps d'une fonction pour inférer eux-même les types "manuellement".
Elle est affichée au survol dans ton éditeur ou avec les commandes :info ou :type dans ghci.
C'est quand même mieux de faire une requête simple (ta requête deux posts plus haut est déjà plus longue que celle avec ON CONFLICT) que plusieurs, non ?
Pour le point 2), pour éviter les phantom reads il faut utiliser le niveau d'isolation serializable, niveau où les requêtes peuvent échouer. Ça complique encore plus la chose (alors que l'upsert est atomique).
[^] # Re: Oui mais
Posté par n_e . En réponse au journal Non, l'inférence de types n'est pas du typage faible. Oui, elle rend les programmes plus lisibles. Évalué à 0.
Ce n'est pas parce que c'est simple à écrire que c'est simple à remarquer (il y a par exemple le cas fréquent d'une fonction sur les chaînes de caractères qui s'appliquent souvent aussi à des tableaux, mais il y a énormément de cas moins évidents).
Haskell est un des langages avec la meilleure inférence de types, c'est dommage de faire le boulot du compilateur à la main et en moins bien.
[^] # Re: Oui mais
Posté par n_e . En réponse au journal Non, l'inférence de types n'est pas du typage faible. Oui, elle rend les programmes plus lisibles. Évalué à 2.
En Haskell (je ne connais pas Elm) ce n'est pas nécessaire. Tu as d'ailleurs intérêt à ne pas le faire car cela te permet de te rendre compte que ta fonction est plus générique que ce que tu pensais en l'écrivant.
Elle est affichée au survol dans ton éditeur ou avec les commandes :info ou :type dans ghci.
[^] # Re: Remarque
Posté par n_e . En réponse au journal Vérifiez vos types avec TypeScript et io-ts. Évalué à 1.
Tu as raison, ça aurait en plus permis de voir que je ne cache pas de boilerplate ou de complexité en ne mettant qu'un bout de fichier.
Oui, c'est volontaire, le type se définit "tout seul" vu la façon dont io-ts est lui-même déclaré.
C'est possible de définir une interface sans tout retaper en faisant comme ça :
Et évidemment si tu utilises VSCode ou autres tu vois tout le détail des types.
[^] # Re: not exists
Posté par n_e . En réponse au journal UPSERT dans PostgreSQL ça déchire. Évalué à 2.
C'est quand même mieux de faire une requête simple (ta requête deux posts plus haut est déjà plus longue que celle avec ON CONFLICT) que plusieurs, non ?
Pour le point 2), pour éviter les phantom reads il faut utiliser le niveau d'isolation serializable, niveau où les requêtes peuvent échouer. Ça complique encore plus la chose (alors que l'upsert est atomique).