>pas de généricité contrainte.
Tu peux expliquer ?
En faisant simple, c'est de pouvoir contraindre un parametre générique à n'etre que d'un certains type, par exemple:
ENSEMBLE_ORDONNE<T : COMPARABLE>
Un ensemble ordonné ne peut contenir que des elements qui sont comparables entres-eux.
... la covariance peut tout à fait être envisagé par les arguments de méthodes passés en référence ...
On parle de la covaraince du type de retour (du resultat quoi) qui à l'avantage d'etres sûr du point de vue des types.
Même si il n'y a pas de covariance, il n'y a pas de limitation, puisque le but peut être atteind autrement
Non! Contre exemple : En C il n'y a riens pour faire de l'objet et il y a donc des limitations pour faire de l'objet, meme si on peut faire autrement.
Avoir la possibilité de la covariance est vraiment interressant (et ne coute vraiment rien au langage). Ne pas l'avoir inclu dans un langage recent est une erreur, surtout quand ce langage n'a pas vraiment pour but d'etres simple (cf la fin de ce post).
>pas de visibilité flexible
Alors là c'est vraiment discutable.
Il suffit d'avoir une interface I ...
Non ce n'est pas discutable. Il ne propose pas de visibilité flexible point. Ta proposition est un hack immonde qui rendrait incompréhensible n'importe quelle bibliothèque un peu volumineuse. De plus ta solution n'est pas réalisable quand ce n'est pas toi qui a concu la bibliothèque.
l'heritage multiple n'est pas indispensable
Bin si justement, il est indispensable pour une bonne modélisation et pour éviter certaines duplication de codes.
Comme pour tout tes autres arguments précédent: effectivement on peut éviter d'utiliser l'héritage multiple mais dans certains cas tu sera embeter de ne pas l'avoir et du coup tu contournera le problème en duplicant ton code.
Ce concept peut très bien envisager avec une méthode orientée aspect...
Laisse les Aspect ou ils sont! Ajouter les aspect c'est introduire un nouveau paradigme (trés criticable en plus) dans un langage qui ferrait biens mieux de se concentrer sur l'aspect objet. Par contre l'ajout d'une methode à une classe aurrait etait une vraie nouvauté interressante (pour la version dynamique, je suis d'accort avec toi: je ne vois pas encore l'utilité ...)
Donne moi le nom d'un seul langage "moderne" qui intègre tout tes killerfeatures
Eiffel propose tout cela, et est portable (niveau source) sur beaucoup d'architecture.
Mais de toutes facon le problème n'est pas de te donner un exemple car voila maintenant pourquoi C# est nul:
Le C# est l'un des dernier langages industriels (qui se veut trés utilisables donc) sorti. Or il n'a apporté aucune amélioration ni innovation notoire. Pire même, il a repris des scories incompréhensible pour un langage objet du "21eme siecle" : en l'occurence, le mot clef "virtual". Le fait même d'avoir conservé ce mot clef devrait faire condamner ce langage par toutes personnes ayant compris le paradigme objet. De plus, l'ajout de ce mot clef empeche de langage de se prétendre vraiment "simple", du coup pourquoi ne pas avoir ajouter d'autres possibilitées plus "évoluées" (héritage multiple, covariance, types ancrés ...)
Java lui etait innovant pour l'epoque (un langage industriel multi-plateforme, pouvant etres orienté web, suffisament efficace, avec un gc et possédant un framework unifié et trés complet): il se voulait simple et a expliqué comme ca tous les manques que l'on pouvait lui reproché (généricité, héritage multiple ...)
Java ajoute maintenant certaines fonctionalitées, c'est plutot biens mais il ne faut pas réver: esseyer de faire évoluer un langage qui se voulait simple vers un langage proposant toutes les fonctionalitées possibles ne peut pas conserver une bonne intégration. Mais bon c'est un moindre mal.
Donc voila pourquoi C# est minable comparé à Java: il n'apporte riens, ou plutot apporte n'importe-quoi.
!Par contre! La plateforme .Net est une vraie innovation: la possiblitée de mélanger différents langages sur une VM. Mais sur ce sujet, je suis plutot sceptique sur la reelle pertinance.
Ok ca permet de réutiliser des bibliothèque d'autres langages plus rapidement, mais l'intégration ne peut pas vraiment etres homogéne et si on choisi un langage possédant un framework complet, cela devient inutile.
Mais cela a au moins le mérite d'avoir était proposé.
[^] # Re: révolutionnaire !
Posté par thecat . En réponse à la dépêche Java 2 Standard Edition version 5.0. Évalué à 7.
>pas de généricité contrainte.
Tu peux expliquer ?
En faisant simple, c'est de pouvoir contraindre un parametre générique à n'etre que d'un certains type, par exemple:
ENSEMBLE_ORDONNE<T : COMPARABLE>
Un ensemble ordonné ne peut contenir que des elements qui sont comparables entres-eux.
... la covariance peut tout à fait être envisagé par les arguments de méthodes passés en référence ...
On parle de la covaraince du type de retour (du resultat quoi) qui à l'avantage d'etres sûr du point de vue des types.
Même si il n'y a pas de covariance, il n'y a pas de limitation, puisque le but peut être atteind autrement
Non! Contre exemple : En C il n'y a riens pour faire de l'objet et il y a donc des limitations pour faire de l'objet, meme si on peut faire autrement.
Avoir la possibilité de la covariance est vraiment interressant (et ne coute vraiment rien au langage). Ne pas l'avoir inclu dans un langage recent est une erreur, surtout quand ce langage n'a pas vraiment pour but d'etres simple (cf la fin de ce post).
>pas de visibilité flexible
Alors là c'est vraiment discutable.
Il suffit d'avoir une interface I ...
Non ce n'est pas discutable. Il ne propose pas de visibilité flexible point. Ta proposition est un hack immonde qui rendrait incompréhensible n'importe quelle bibliothèque un peu volumineuse. De plus ta solution n'est pas réalisable quand ce n'est pas toi qui a concu la bibliothèque.
l'heritage multiple n'est pas indispensable
Bin si justement, il est indispensable pour une bonne modélisation et pour éviter certaines duplication de codes.
Comme pour tout tes autres arguments précédent: effectivement on peut éviter d'utiliser l'héritage multiple mais dans certains cas tu sera embeter de ne pas l'avoir et du coup tu contournera le problème en duplicant ton code.
Ce concept peut très bien envisager avec une méthode orientée aspect...
Laisse les Aspect ou ils sont! Ajouter les aspect c'est introduire un nouveau paradigme (trés criticable en plus) dans un langage qui ferrait biens mieux de se concentrer sur l'aspect objet. Par contre l'ajout d'une methode à une classe aurrait etait une vraie nouvauté interressante (pour la version dynamique, je suis d'accort avec toi: je ne vois pas encore l'utilité ...)
Donne moi le nom d'un seul langage "moderne" qui intègre tout tes killerfeatures
Eiffel propose tout cela, et est portable (niveau source) sur beaucoup d'architecture.
Mais de toutes facon le problème n'est pas de te donner un exemple car voila maintenant pourquoi C# est nul:
Le C# est l'un des dernier langages industriels (qui se veut trés utilisables donc) sorti. Or il n'a apporté aucune amélioration ni innovation notoire. Pire même, il a repris des scories incompréhensible pour un langage objet du "21eme siecle" : en l'occurence, le mot clef "virtual". Le fait même d'avoir conservé ce mot clef devrait faire condamner ce langage par toutes personnes ayant compris le paradigme objet. De plus, l'ajout de ce mot clef empeche de langage de se prétendre vraiment "simple", du coup pourquoi ne pas avoir ajouter d'autres possibilitées plus "évoluées" (héritage multiple, covariance, types ancrés ...)
Java lui etait innovant pour l'epoque (un langage industriel multi-plateforme, pouvant etres orienté web, suffisament efficace, avec un gc et possédant un framework unifié et trés complet): il se voulait simple et a expliqué comme ca tous les manques que l'on pouvait lui reproché (généricité, héritage multiple ...)
Java ajoute maintenant certaines fonctionalitées, c'est plutot biens mais il ne faut pas réver: esseyer de faire évoluer un langage qui se voulait simple vers un langage proposant toutes les fonctionalitées possibles ne peut pas conserver une bonne intégration. Mais bon c'est un moindre mal.
Donc voila pourquoi C# est minable comparé à Java: il n'apporte riens, ou plutot apporte n'importe-quoi.
!Par contre! La plateforme .Net est une vraie innovation: la possiblitée de mélanger différents langages sur une VM. Mais sur ce sujet, je suis plutot sceptique sur la reelle pertinance.
Ok ca permet de réutiliser des bibliothèque d'autres langages plus rapidement, mais l'intégration ne peut pas vraiment etres homogéne et si on choisi un langage possédant un framework complet, cela devient inutile.
Mais cela a au moins le mérite d'avoir était proposé.