>On parle de la covaraince du type de retour
je sais ce qu'est la covariance, ce que j'ai voulu te dire, c'est que C# a le mot clé ref qui permet d'effectuer des passages par référence et donc de "retourner" plusieurs valeurs, là encore avec vérification du type, puisque celà semble être un bon critère.
Ca n'a absolument pas le même but. La covariance permet une modélisation élégante et efficace.
Une bibliothèque n'est pas censé être modifiée ... tout ce qu'on peut faire c'est utiliser des constructions de la bibliothèque en les spécialisant par héritage
Je veut changer la visibilité de certaines methodes de ma super-classe, je fait comment? Tu propose de définir une interface pour chaque exportation possible, je doit donc creer une interface spécifique (et qui ne servira à riens d'autres) pour chaque clause d'exportation? Tu trouve toujours cela "élégant"?
Au sujet des Aspect ...
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; je ne trouve cela vraiment pas adapté. Le problème est juste d'avoir la possibilité d'ajouter une methode à une classe (en statique, la classe n'etant pas la tienne tu ne peut pas toucher le code). La possibilité de manipuler une classe et de lui ajouter une méthode est loins d'etre compliqué au point d'inventer des mecanismes super sofistiqués (et surtout qui rompent avec la conception objet).
[sous .Net] tu as accès de manière uniforme aux API du frameworks, et pourtant tu ne sais strictement pas dans quel langage il a été codé...
Tu Oubli de dire que pour réaliser cela il faut absolument que les API respectent un certains guide-de-compatibilité (je ne me rapelle plus l'appelation) et du coup ceux qui font les API, ne peuvent pas reellement exploiter toutes les possibilitées du langage qu'ils utilisent si ils veulent etres "compliant".
Mois si j'utilise un langage foncitonel, c'est pas pour faire de l'objet. Si je fait une biliothèque en langage fonctionel, Ok, elle sera directement utilisable sous d'autres langages grace à .Net, mais elle ne sera pas homogène dans mon autres programe qui l'utilise écrit lui en C#.
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.
Non pas forcement, il y a toujours une autre solution.
Dur a suivre si on ne ce répond pas dans le même sens! ;-)
Non il n'y a pas d'autres solution que de dupliquer ton code. Je suis déja tomber 3 fois sur un cas identique et impossible de trouver une echapatoire! (non ce n'est pas moi qui suit mauvais, mais Ok cela reste -heureusement- peu fréquent)
Au sujet des mixins (du post du dessu) il est vrais qu'ils se propose d'étres une alternative à l'héritage multiple, mais je ne trouve pas leur utilisation reelement plus simple.
Au sujet du "Virtual" ...
Toujours les même arguments.
Sur la performance, c'est n'importe quoi: .Net est une machine virtuelle! donc ce n'est pas sur un petit appel de méthode que l'on va gagner les perf! Pour la version compilé (je sais que tu va m'en parler) des langages propose des methodes "tout" virtuel et une implémentation trés trés veloce! (biens meilleure que pour le C++ par exemple) donc l'argument ne tiens plus vraiment la route avec les progrés des compilo de nos jours.
Pour le versionning, c'est pareil, des langages proposent du tout virtuel sans avoir de scories dans les bibliothèques qu'ils proposent. Dans le pire des cas le mot "final" (ou son equivalent) existait pour les cas trop critique.
Bref rien de neuf, avoir gardé ce mot est vraiment une grande erreur.
[Java était innovant] Dommage que ce n'est pas le cas de cette version
Tu est un peu dur, Java ajoute enormément de chose par rapport à son propre langage (mais pas par rapport au autres Ok)
Mais surtout, Java abandonne l'aspect "langage trés simple" qu'il avait.
[Eiffel] facilite-t-il la réutilisation de l'existant ? Ah vi y'a une méthode simple : il cible .NET ;)
C'est de la pire mauvaise fois (heureusement qu'il y a le smiley!): Eiffel facilite la réutilisation des bibliothque à un point qu'aucun langage compilé à typage statique n'a atteint.
La possibilité de le compiler vers .Net n'est qu'une démarche commerciale: Eiffel est déja multiplateforme (OK seulement Win et Linux mais c'est déja pas mal), possède un héritage multiple, des types ancré, des assertions trés puissantes, ... alors je ne pense pas que cela soit pour réutiliser les bibliothèque de .Net qui ne proposent aucune des ces possibilitées.
La encore on voit a quel point l'utilité de .Net est limitée: Je vais vouloir réutiliser des bibliothèque de .Net dans mon programme Eiffel? Elles serons modélisé avec un héritage simple et n'utiliserons pas la puissance du langage de mon application cible.
Un gros avantage est de pouvoir rapidement utilisé ces bibliothèque, mais cela n'est pas une solution vraiment idéale que de jongler intelectuelement avec différentes conceptions.
[^] # Re: révolutionnaire !
Posté par thecat . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 4.
je sais ce qu'est la covariance, ce que j'ai voulu te dire, c'est que C# a le mot clé ref qui permet d'effectuer des passages par référence et donc de "retourner" plusieurs valeurs, là encore avec vérification du type, puisque celà semble être un bon critère.
Ca n'a absolument pas le même but. La covariance permet une modélisation élégante et efficace.
Une bibliothèque n'est pas censé être modifiée ... tout ce qu'on peut faire c'est utiliser des constructions de la bibliothèque en les spécialisant par héritage
Je veut changer la visibilité de certaines methodes de ma super-classe, je fait comment? Tu propose de définir une interface pour chaque exportation possible, je doit donc creer une interface spécifique (et qui ne servira à riens d'autres) pour chaque clause d'exportation? Tu trouve toujours cela "élégant"?
Au sujet des Aspect ...
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; je ne trouve cela vraiment pas adapté. Le problème est juste d'avoir la possibilité d'ajouter une methode à une classe (en statique, la classe n'etant pas la tienne tu ne peut pas toucher le code). La possibilité de manipuler une classe et de lui ajouter une méthode est loins d'etre compliqué au point d'inventer des mecanismes super sofistiqués (et surtout qui rompent avec la conception objet).
[sous .Net] tu as accès de manière uniforme aux API du frameworks, et pourtant tu ne sais strictement pas dans quel langage il a été codé...
Tu Oubli de dire que pour réaliser cela il faut absolument que les API respectent un certains guide-de-compatibilité (je ne me rapelle plus l'appelation) et du coup ceux qui font les API, ne peuvent pas reellement exploiter toutes les possibilitées du langage qu'ils utilisent si ils veulent etres "compliant".
Mois si j'utilise un langage foncitonel, c'est pas pour faire de l'objet. Si je fait une biliothèque en langage fonctionel, Ok, elle sera directement utilisable sous d'autres langages grace à .Net, mais elle ne sera pas homogène dans mon autres programe qui l'utilise écrit lui en C#.
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.
Non pas forcement, il y a toujours une autre solution.
Dur a suivre si on ne ce répond pas dans le même sens! ;-)
Non il n'y a pas d'autres solution que de dupliquer ton code. Je suis déja tomber 3 fois sur un cas identique et impossible de trouver une echapatoire! (non ce n'est pas moi qui suit mauvais, mais Ok cela reste -heureusement- peu fréquent)
Au sujet des mixins (du post du dessu) il est vrais qu'ils se propose d'étres une alternative à l'héritage multiple, mais je ne trouve pas leur utilisation reelement plus simple.
Au sujet du "Virtual" ...
Toujours les même arguments.
Sur la performance, c'est n'importe quoi: .Net est une machine virtuelle! donc ce n'est pas sur un petit appel de méthode que l'on va gagner les perf! Pour la version compilé (je sais que tu va m'en parler) des langages propose des methodes "tout" virtuel et une implémentation trés trés veloce! (biens meilleure que pour le C++ par exemple) donc l'argument ne tiens plus vraiment la route avec les progrés des compilo de nos jours.
Pour le versionning, c'est pareil, des langages proposent du tout virtuel sans avoir de scories dans les bibliothèques qu'ils proposent. Dans le pire des cas le mot "final" (ou son equivalent) existait pour les cas trop critique.
Bref rien de neuf, avoir gardé ce mot est vraiment une grande erreur.
[Java était innovant] Dommage que ce n'est pas le cas de cette version
Tu est un peu dur, Java ajoute enormément de chose par rapport à son propre langage (mais pas par rapport au autres Ok)
Mais surtout, Java abandonne l'aspect "langage trés simple" qu'il avait.
[Eiffel] facilite-t-il la réutilisation de l'existant ? Ah vi y'a une méthode simple : il cible .NET ;)
C'est de la pire mauvaise fois (heureusement qu'il y a le smiley!): Eiffel facilite la réutilisation des bibliothque à un point qu'aucun langage compilé à typage statique n'a atteint.
La possibilité de le compiler vers .Net n'est qu'une démarche commerciale: Eiffel est déja multiplateforme (OK seulement Win et Linux mais c'est déja pas mal), possède un héritage multiple, des types ancré, des assertions trés puissantes, ... alors je ne pense pas que cela soit pour réutiliser les bibliothèque de .Net qui ne proposent aucune des ces possibilitées.
La encore on voit a quel point l'utilité de .Net est limitée: Je vais vouloir réutiliser des bibliothèque de .Net dans mon programme Eiffel? Elles serons modélisé avec un héritage simple et n'utiliserons pas la puissance du langage de mon application cible.
Un gros avantage est de pouvoir rapidement utilisé ces bibliothèque, mais cela n'est pas une solution vraiment idéale que de jongler intelectuelement avec différentes conceptions.