L’intérêt, c’est de ne pas avoir à déclarer explicitement l’implémentation (le terme est mauvais, je ne sais plus quel est le bon) d’un trait. Ce qui permet, notamment, si moi je définis un nouveau trait, et qu’il se trouve qu’un type de la lib standard/xyz respecte l’ensemble des propriétés de ce trait (et donc, est substituable au sens du LSP), que je l’utilise partout où j’ai déclaré que j’utilisais un type implémentant mon trait, même s’il ne déclare pas l’implémenter explicitement (je ne peux pas modifier la lib standard ou la lib xyz pour y rajouter mon trait).
Pour pratiquer cela couramment en C++, c’est utile. Mon impression est qu’avec un système de traits explicites, tu te restreins arbitrairement. Ça me fait un peu penser à de la généricité contrainte par classe de base, même si ce n’est pas tout à fait la même chose.
Après, il y des arguments pour ne pas l’avoir fait :
- ça simplifie beaucoup le boulot du compilateur
- l’existence et la signature d’une méthode (la seule chose que sait vérifier à ce niveau le compilo rust) ne suffisent pas à ce que sa sémantique soit identique / compatibles -> avec des traits explicites, on fait reposer cette responsabilité sur le développeur.
Note que le deuxième point pourrait grandement être corrigé par... la programmation par contrat :).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0
[^] # Re: Premières impressions
Posté par whity . En réponse à la dépêche Rust 1.0, entrée dans la période stable. Évalué à 3.
L’intérêt, c’est de ne pas avoir à déclarer explicitement l’implémentation (le terme est mauvais, je ne sais plus quel est le bon) d’un trait. Ce qui permet, notamment, si moi je définis un nouveau trait, et qu’il se trouve qu’un type de la lib standard/xyz respecte l’ensemble des propriétés de ce trait (et donc, est substituable au sens du LSP), que je l’utilise partout où j’ai déclaré que j’utilisais un type implémentant mon trait, même s’il ne déclare pas l’implémenter explicitement (je ne peux pas modifier la lib standard ou la lib xyz pour y rajouter mon trait).
Pour pratiquer cela couramment en C++, c’est utile. Mon impression est qu’avec un système de traits explicites, tu te restreins arbitrairement. Ça me fait un peu penser à de la généricité contrainte par classe de base, même si ce n’est pas tout à fait la même chose.
Après, il y des arguments pour ne pas l’avoir fait :
- ça simplifie beaucoup le boulot du compilateur
- l’existence et la signature d’une méthode (la seule chose que sait vérifier à ce niveau le compilo rust) ne suffisent pas à ce que sa sémantique soit identique / compatibles -> avec des traits explicites, on fait reposer cette responsabilité sur le développeur.
Note que le deuxième point pourrait grandement être corrigé par... la programmation par contrat :).
Mes commentaires sont en wtfpl. Une licence sur les commentaires, sérieux ? o_0