Ce sont, à ma connaissance, les fondateurs de Sather, langage issu de Eiffel, qui ont prétendu que l'utilisation de la contravariance renforçait la sécurité du code.
Non, non, il s'agit d'un résultat général connu des théoriciens des langages de programmation, ce n'est absolument pas spécifique à Sather.
Dans un système de types avec sous-typage, on cherche à savoir quand on peut redéfinir ou pas une méthode, et quelles sont les contraintes à avoir sur les types des méthodes pour que le programme soit bien typé. On se trouve là en présence d'un problème indécidable. Mais, si on restreint la redéfinition à la contravariance sur les paramètres, alors on sait que le programme sera bien typé.
Ça ne veut pas dire que toute forme de covariance est à proscrire, simplement qu'il y a des cas où ça produira des programmes acceptés par le compilateur qui produiront quand même une erreur de type.
Un exemple que certaines formes de covariance sont acceptables, tu le donnes: c'est l'exemple des méthodes "binaires" (style is_equal). En fait, on sait qu'on peut accepter toutes les méthodes avec contravariance et toutes les méthodes binaires.
Le problème d'Eiffel, c'est qu'il permet plus que les méthodes binaires, car on peut employer like avec autre chose que Current, et obtenir ainsi des méthodes avec covariance, qu'Eiffel acceptera, peut-être à tort.
Ca fait deux ans que j'utilise Eiffel au travail, et le problème de la covariance / contravariance ne s'est jamais posé pour moi.
Mais ça tu n'en sais rien justement! Tu peux juste dire que, pour toutes les exécutions de tes programmes Eiffel utilisant la covariance, il n'y a pas eu de plantage. Mais rien ne te garantit plus que ça n'arrivera pas avec certaines données que tu n'as pas encore testées.
C'est justement le principe du typage fort que de te garantir qu'il n'y aura jamais d'erreur de type.
[^] # Re: Et le Troll, il arrive quand ?
Posté par Anaximandre . En réponse à la dépêche Une nouvelle version stable de SmartEiffel. Évalué à 3.
Non, non, il s'agit d'un résultat général connu des théoriciens des langages de programmation, ce n'est absolument pas spécifique à Sather.
Dans un système de types avec sous-typage, on cherche à savoir quand on peut redéfinir ou pas une méthode, et quelles sont les contraintes à avoir sur les types des méthodes pour que le programme soit bien typé. On se trouve là en présence d'un problème indécidable. Mais, si on restreint la redéfinition à la contravariance sur les paramètres, alors on sait que le programme sera bien typé.
Ça ne veut pas dire que toute forme de covariance est à proscrire, simplement qu'il y a des cas où ça produira des programmes acceptés par le compilateur qui produiront quand même une erreur de type.
Un exemple que certaines formes de covariance sont acceptables, tu le donnes: c'est l'exemple des méthodes "binaires" (style is_equal). En fait, on sait qu'on peut accepter toutes les méthodes avec contravariance et toutes les méthodes binaires.
Le problème d'Eiffel, c'est qu'il permet plus que les méthodes binaires, car on peut employer like avec autre chose que Current, et obtenir ainsi des méthodes avec covariance, qu'Eiffel acceptera, peut-être à tort.
Ca fait deux ans que j'utilise Eiffel au travail, et le problème de la covariance / contravariance ne s'est jamais posé pour moi.
Mais ça tu n'en sais rien justement! Tu peux juste dire que, pour toutes les exécutions de tes programmes Eiffel utilisant la covariance, il n'y a pas eu de plantage. Mais rien ne te garantit plus que ça n'arrivera pas avec certaines données que tu n'as pas encore testées.
C'est justement le principe du typage fort que de te garantir qu'il n'y aura jamais d'erreur de type.