Ca n'a absolument pas le même but.
Désolé, je me suis planté de mot clé : c'est le mot clé "out" dont je voulais parler :) (Mais sinon explique moi le but de la covariance par rapport à "out")
Je veut changer la visibilité de certaines methodes de ma super-classe, je fait comment?
Pour moi soit tu es le développeur, et tu as accès au source, tu peux modifier l'accessibilité. Sinon je vois vraiment pas l'intérêt de laisser la possibilité aux utilisateurs de modifier l'accès aux attributs et méthodes d'une classe... Ca va tout péter la signature de la classe !
Tu propose comme solution d'introduire tout un nouveau paradigme de programmation, qui est en plus trés criticable au niveau de l'utilisabilitée réelle;
Pour l'ajout de méthode, pareil qu'au dessus, donne moi un exemple élégant qui me permette celà, avec bien entendu un exemple où celà a un intérêt et qui ne casse pas toute la signature de ma classe. J'ai vraiment des doutes quand à l'utilité réelle.
Tu Oubli de dire que pour réaliser cela il faut absolument que les API respectent un certains guide-de-compatibilité
Tout à fait : CLI (Common Language Interface)
En effet si tu veux garantir la réutlilisabilité de tes API, il faut mieux respecter ces règles (même si t'es pas obligé), mais à l'intérieur de ton code, tu peux utiliser toutes les fonctionnalités du langage, seules les parties exposées doivent être conformes. Pareil à l'utilisation, si ton langage support l'héritage multiple, il peut utiliser des classes conçues en héritage simple.
Cepandant je le répète la posibilité de diretement réutilisé une bibliothqèue existante est super-pratique, mais ce n'est vraiment pas idéal.
C'est quoi l'idéal ?
Je suis déja tomber 3 fois sur un cas identique et impossible de trouver une echapatoire!
Vas-y balance :)
Ensuite on va voir si c'est pas contournable et si celà ne va pas poser des problèmes potentiels :)
Sur la performance, c'est n'importe quoi
Me semble que ce n'est qu'un argument, contestable effectivement, mais le 2ème est déjà mieux : le créateur de C# pense qu'il est préférable de fermer la possibilité de modifier une méthode par défaut, plutôt que l'inverse, pour des tas de raisons (d'abord le programmeur ne s'en soucis pas, il ne documente pas la possibilité et l'impact d'une méthode sur les attributs d'une classe et son état, etc.) Pleins de bonnes raisons à mon goût, même si celà va à l'encontre du paradigme "objet". Et puis dans la pratique personne ne s'en plaint.
Tu est un peu dur, Java ajoute enormément de chose par rapport à son propre langage
Vi c'est ce que j'ai dis plus haut (ou plus bas), c'est bien pour le langage, mais celà ne créé pas d'émulation, et je trouve ca vraiment dommage.
C'est de la pire mauvaise fois (heureusement qu'il y a le smiley!)
C'était juste pour la vanne :)
Je parlais principalement de la réutilisation de code d'API natifs, notamment de d'API écrit en C ou dans d'autres langages, la réutilisation du code écrit en Eiffel je m'en doute ;)
Donc alors la réutilisabilité de l'existant ? (pas de l'existant Eiffel)
[^] # Re: révolutionnaire !
Posté par TImaniac (site web personnel) . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 2.
Désolé, je me suis planté de mot clé : c'est le mot clé "out" dont je voulais parler :) (Mais sinon explique moi le but de la covariance par rapport à "out")
Je veut changer la visibilité de certaines methodes de ma super-classe, je fait comment?
Pour moi soit tu es le développeur, et tu as accès au source, tu peux modifier l'accessibilité. Sinon je vois vraiment pas l'intérêt de laisser la possibilité aux utilisateurs de modifier l'accès aux attributs et méthodes d'une classe... Ca va tout péter la signature de la classe !
Tu propose comme solution d'introduire tout un nouveau paradigme de programmation, qui est en plus trés criticable au niveau de l'utilisabilitée réelle;
Pour l'ajout de méthode, pareil qu'au dessus, donne moi un exemple élégant qui me permette celà, avec bien entendu un exemple où celà a un intérêt et qui ne casse pas toute la signature de ma classe. J'ai vraiment des doutes quand à l'utilité réelle.
Tu Oubli de dire que pour réaliser cela il faut absolument que les API respectent un certains guide-de-compatibilité
Tout à fait : CLI (Common Language Interface)
En effet si tu veux garantir la réutlilisabilité de tes API, il faut mieux respecter ces règles (même si t'es pas obligé), mais à l'intérieur de ton code, tu peux utiliser toutes les fonctionnalités du langage, seules les parties exposées doivent être conformes. Pareil à l'utilisation, si ton langage support l'héritage multiple, il peut utiliser des classes conçues en héritage simple.
Cepandant je le répète la posibilité de diretement réutilisé une bibliothqèue existante est super-pratique, mais ce n'est vraiment pas idéal.
C'est quoi l'idéal ?
Je suis déja tomber 3 fois sur un cas identique et impossible de trouver une echapatoire!
Vas-y balance :)
Ensuite on va voir si c'est pas contournable et si celà ne va pas poser des problèmes potentiels :)
Sur la performance, c'est n'importe quoi
Me semble que ce n'est qu'un argument, contestable effectivement, mais le 2ème est déjà mieux : le créateur de C# pense qu'il est préférable de fermer la possibilité de modifier une méthode par défaut, plutôt que l'inverse, pour des tas de raisons (d'abord le programmeur ne s'en soucis pas, il ne documente pas la possibilité et l'impact d'une méthode sur les attributs d'une classe et son état, etc.) Pleins de bonnes raisons à mon goût, même si celà va à l'encontre du paradigme "objet". Et puis dans la pratique personne ne s'en plaint.
Tu est un peu dur, Java ajoute enormément de chose par rapport à son propre langage
Vi c'est ce que j'ai dis plus haut (ou plus bas), c'est bien pour le langage, mais celà ne créé pas d'émulation, et je trouve ca vraiment dommage.
C'est de la pire mauvaise fois (heureusement qu'il y a le smiley!)
C'était juste pour la vanne :)
Je parlais principalement de la réutilisation de code d'API natifs, notamment de d'API écrit en C ou dans d'autres langages, la réutilisation du code écrit en Eiffel je m'en doute ;)
Donc alors la réutilisabilité de l'existant ? (pas de l'existant Eiffel)