J'ai eu le cas inverse en réécrivant une lib Python perso fortement basée sur generic + héritage.
Une lib pour faire des tables de rapports pdf avec gestion des cumuls, ruptures, sauts de pages & co avec comme principe que chaque colonne peut contenir n'importe quel type d'objet. Une lib que j'utilise dans quasiment tous mes projets.
Un vrai casse tête à réécrire en Go donc, sans generic ni héritage.
Finalement je me suis basé entièrement sur des closures et composition.
Miraculeusement j'ai réussi à ce que ça tienne en moins de ligne de code mais surtout j'évite ainsi tous les effets de bords qu'on retrouve avec trop de generic et héritage et mon code est beaucoup plus facile à maintenir malgré le fait qu'il soit utilisé dans beaucoup de projets.
Aussi ma conclusion pour le moment c'est que le generic c'est bien pour des codes très réduits et dont les fonctionnalités ne doivent plus bouger mais sur des libs plus grosses, comme toute dépendance c'est très difficile à faire évoluer.
Et encore, même pour des codes réduits, en Go on a l'habitude de faire des petites boucles à tous les coins de rues, pas sûr qu'on y gagne à les remplacer par des fonctions...
J'avoue qu'il faudrait montrer du code pour voir de quoi on parle !
[^] # Re: Trou de mémoire
Posté par wilk (site web personnel, Mastodon) . En réponse au lien Go 1.18 Beta : la généricité enfin !. Évalué à 3.
J'ai eu le cas inverse en réécrivant une lib Python perso fortement basée sur generic + héritage.
Une lib pour faire des tables de rapports pdf avec gestion des cumuls, ruptures, sauts de pages & co avec comme principe que chaque colonne peut contenir n'importe quel type d'objet. Une lib que j'utilise dans quasiment tous mes projets.
Un vrai casse tête à réécrire en Go donc, sans generic ni héritage.
Finalement je me suis basé entièrement sur des closures et composition.
Miraculeusement j'ai réussi à ce que ça tienne en moins de ligne de code mais surtout j'évite ainsi tous les effets de bords qu'on retrouve avec trop de generic et héritage et mon code est beaucoup plus facile à maintenir malgré le fait qu'il soit utilisé dans beaucoup de projets.
Aussi ma conclusion pour le moment c'est que le generic c'est bien pour des codes très réduits et dont les fonctionnalités ne doivent plus bouger mais sur des libs plus grosses, comme toute dépendance c'est très difficile à faire évoluer.
Et encore, même pour des codes réduits, en Go on a l'habitude de faire des petites boucles à tous les coins de rues, pas sûr qu'on y gagne à les remplacer par des fonctions...
J'avoue qu'il faudrait montrer du code pour voir de quoi on parle !