Articles précédents : Articles
- [41] Sun pousse pour que le format des documents OOo devienne une norme
- [94] Le Venezuela, deux fois !
- [24] Red Hat rachète Netscape Enterprise Suite
- [87] Le brevet Microsoft sur la FAT est rejeté
- [10] Netconsole, log de messages noyaux via UDP
- [20] Opquast : sortie de la version 1.0
- [11] La Banquise : moteur de recherche libre sur le libre
- [169] Portable à 1 euro par jour : aussi sous GNU/LINUX
- [64] UFC-Que choisir déplore le manque d'interopérabilité dans la musique en ligne
- [17] Vulnérabilité via des formats d'images : Windows - GNU/Linux
Liens connexes
- Page de J2SE 5.0 chez Sun (2213 hits)
- J2SE 5.0 in a Nutshell (848 hits)
- J2SE 5.0 New Features and Enhancements (922 hits)
Dépêche modérée par
Dépêche éditée par
Articles : Java 2 Standard Edition version 5.0
Posté par Christophe Jacquet (page perso, ). Modéré le 03 octobre 2004.
Du côté des nouveautés du langage, on trouve : les types génériques, l'"autoboxing", la possibilité d'associer des métadonnées au code, une boucle du genre "foreach", l'import statique, les énumérations, des fonctions à nombre d'arguments variables, une lecture plus facile des données d'entrées, une nouvelle gestion de la synchronisation, et une génération d'interfaces RMI plus facile.
S'y ajoutent de nombreuses améliorations en termes de performances, de diagnostic et de disponibilité.
![[en]](../../../images/en.png)
Page de J2SE 5.0 chez Sun (2213 hits)-
J2SE 5.0 in a Nutshell (848 hits)
-
J2SE 5.0 New Features and Enhancements (922 hits)
> Lire la dépêche (262 commentaires, moyenne: 2,4).
- les types génériques correspondent aux "templates" de C++ : ainsi un vecteur de chaînes peut maintenant être écrit comme tel et non plus comme un vecteur d'objets quelconques dont il fallait transtyper les éléments à chaque utilisation...
- l'autoboxing permet la conversion implicite et automatique entre les types natifs et leurs homologues objets, par exemple entre "int" et "Integer"
- avec les métadonnées, on peut ajouter des balises au code, à destination du compilateur ou d'autres outils (par exemple pour la génération automatique de code)
- la boucle for permet maintenant de parcourir chaque élément d'une collection d'objets: for(Integer i : list) { ... }
- grâce à l'import statique, on peut éviter d'avoir à préfixer le nom de la classe d'une méthode statique à chaque utilisation. Par exemple, après un "import static java.lang.Math.cos;" on peut appeler directement la fonction cos()
- l'"enum" fonctionne comme en C
- les fonctions à nombre d'arguments variable...permettent d'implémenter printf()... ;-)
- il est plus facile de lire des données formatées sur un flux d'entrée
- le package java.util.concurrent fournit de nouveaux outils pour synchroniser des threads, par exemple des sémaphores
- il n'est plus nécessaire d'utiliser rmic pour la génération d'interfaces RMI.
D'autres nouveautés sont à découvrir : nouveau thème Ocean pour Swing, nouvelle version du support XML, gestion des caractères Unicode sur 32 bits...
Livre
Java 5.0 est tellement une révolution par rapport a Java 1.4 qu'il est dommage qu'il n'existe pas un livre pour parler juste des différences entre ces deux langages... Avec des exemples, comment metre en pratique, des "tips", etc.
Si quelqu'un a une référence à proposer, elle est la bienvenue... Le seul que j'ai trouvé pas trop mal pour le moment et "Java how to program".... Mais à 100$CA, ca fait un peu beaucoup et il est trop généraliste...
JMS
-
[^]Re: Livre
Posté par Flipo () le 03/10/2004 à 17:55. (lien). Évalué à 7.http://www.oreilly.com/catalog/javaadn/index.html(...)
--
Plus je connais les hommes, plus j'aime ma machine.
-
[^]Re: Livre
Posté par Anomaly () le 04/10/2004 à 09:53. (lien). Évalué à 3.Je ne connais pas de livres, mais par contre il existe un article en français qui reprend les nouveautés de Java 5 en détails, si ça t'intéresse :
http://lroux.developpez.com/article/java/tiger/(...)
[+] révolutionnaire !
C'est vraiment révolutionnaire Java 5.0 d'après la news.
On a des trucs (comme en C++) et des machins (comme en C). En gros, on va maintenant presque pouvoir faire de la vraie programmation avec Java...
Ah non, juste, les utilisateurs n'auront pas la machine virtuelle adéquate...
Bon, ben on retourne faire du C, C++ et Python, je n'arrive toujours pas à voir l'intérêt de Java par rapport à ces 3 là
/me, qui a convoqué par avance l'huissier pour constater le record de moinssage dont il va être victime. De toutes façons, ce moinssage n'est rien par rapport avec ce que je vais endurer avec tous les projets en Java que je dois faire cette année...
-
[^]Re: révolutionnaire !
Posté par Stéphane TRAUMAT (page perso, ) le 03/10/2004 à 13:56. (lien). Évalué à 9.ca me fait chier de répondre car c'est un post un peu ridicule mais allons y...
On peut faire de la vrauie programmation en Java.. en fait, je sais pas koi donner comme argument, il y a des softs en java dans tous les domaines, des jeux, des applications serveurs, des site webs, des applis pour PDA... bref..
Les ajouts étaient nécéssaires certes et certains viennent du C et du C++.. maintenant, on attend de voir combien de temps vont mettre C et C++ pour intégrer les bonnes choses de java.. comme la possibilité d'associer des métadonnées au code... on se reparle dans 10 ? ;)
Ah non, juste, les utilisateurs n'auront pas la machine virtuelle adéquate...
La je capte pas ?
Bon, ben on retourne faire du C, C++ et Python, je n'arrive toujours pas à voir l'intérêt de Java par rapport à ces 3 là
Chacun voit les avantages dont il a besoin...
moi je vois la simplicité, le support des leaders du marché, des api jdbc bien fouttues, un paquet de projets libre géniaux comme JOnAS, hibernate, tomcat, XMLBeans, AXis...
une API riche, la portabilité...-
[^]Re: révolutionnaire !
Posté par cykl (Jabber id, ) le 03/10/2004 à 14:37. (lien). Évalué à 9.>> Ah non, juste, les utilisateurs n'auront pas la machine virtuelle adéquate...
> La je capte pas ?
Bha comment je fais du java 5.0 sur mon linux ppc ou NetBSD ppc (j'ose pas mettre FreeBSD ppc par ce qu'il faudrait deja que ca tourne avant de lancer une usine a gaz :-) ?-
[^]Re: révolutionnaire !
Posté par Stéphane TRAUMAT (page perso, ) le 03/10/2004 à 16:29. (lien). Évalué à 1.Disons quy'en développant en java, je vais pouvoir le faire tourner sur un maximum de plateforme... on a jamais dit toutes :)
-
[^]Re: révolutionnaire !
Posté par cykl (Jabber id, ) le 03/10/2004 à 16:38. (lien). Évalué à 5.Ouai donc moi en cours de java avec mon ibook je fais comment ? j'utilise java 1.3 par ce que c'est la derniere de chez Sun qui connait meme pas les regexp...
Si le maximum de plateformes c'est 5 je glousse doucement.
TRAUMAT => tramo ? :-)-
[^]Re: révolutionnaire !
Posté par Stéphane TRAUMAT (page perso, ) le 03/10/2004 à 16:42. (lien). Évalué à 6.TRAUMAT = TRAUMAT :)
Il n'y a pas que SUN qui fait des JVM :
http://www.geocities.com/marcoschmidt.geo/java-jdk-jre.html(...)
elles ne sont pas toutes des 5.0 mais laissez un peu de temps aux gens pour développer... je me permets de rappeller qu'il n'y a pas que sun qui fait des jvm-
[^]Re: révolutionnaire !
Posté par ufoot (page perso, ) le 04/10/2004 à 09:12. (lien). Évalué à 8.Ceci dit c'est un fait, la portabilité de Java reste depuis des années tout à fait théorique, car les implémentations de JVMs ne suivent pas. Pas assez vite pour certaines plate-formes, pas du tout pour d'autres. Java serait 100% portable "si" il y avait une JVM dans la version qui va bien pour chaque plate-forme. Le problème c'est que ce n'est pas le cas... Compare le nombre de plate-formes qui supportent actuellement, aujourd'hui, maintenant, Perl 5.8 ou Java 1.4, y'a pas photo, mais alors vraiment pas.
Ceci dit il y a de belles initiatives. GCJ par exemple est carrément la piste à suivre je pense. Mais le moteur du langage a beau être propre et carré et tout ce que tu veux, tout ça est bien joli mais il faut aussi que les bibliothèques suivent, et GNU ClassPath c'est pas du petit projet qui va être terminé demain. L'enjeu de la portabilité ce n'est pas tant le moteur du langage que ses bibliothèques. Dans ce domaine encore un Perl ou un Python font un carton comparé à Java en terme de nombre de plate-formes supportées.
Alors certes "il sufffit d'attendre". Moi ça fait 7 ans qu'on me raconte que "bientôt une fois que les JVMs seront dispos sur toutes les plates-formes ça sera super ton programme Java il tournera sur n'importe quoi!". Ca commence à sentir le réchauffé et j'y crois plus...-
[^]Re: révolutionnaire !
Posté par Stéphane TRAUMAT (page perso, ) le 04/10/2004 à 09:23. (lien). Évalué à 2.Depuis des années on a du FUD comme ça... Java n'a jamais promis la portabilité sur toutes les plateformes du monde, java a juste dit, vous allez pouvoir développer indépendament de la plateforme et vous allez ensuite pouvoir déployer sur n'importe quelle plateforme qui a une machine virtuelle....
Il y a des JVM pour de nombreuses plateformes et je n'ai pas comparé avec perl.. c'est vrai.-
[^]Re: révolutionnaire !
Posté par ufoot (page perso, ) le 04/10/2004 à 09:41. (lien). Évalué à 4.> Java n'a jamais promis la portabilité sur toutes les plateformes du monde, java a juste dit
write once, run anywhere 8-)
Tu as 100% raison quand tu précise "vous allez ensuite pouvoir déployer sur n'importe quelle plateforme qui a une machine virtuelle...". Le problème est que l'argument "WORA" a été martelé assez longuement et sans trop d'explications sur les vrais détails techniques de la chose. Et là SUN - ou plutôt son service marketting - en sont totalement responsables. Ce sont eux qui ont mis en avant la portabilité à 100%. Evidemment que c'est le marketting qui a poussé ce message et qu'il est faux, car il y a ce petit "oui mais" en forme de "vous avez besoin d'une JVM ad hoc". Maintenant il y en a qui sont déçus parce qu'on leur a promis la lune et ils l'ont pas eue. C'est un juste retour de bâton dans les dents du marketting de SUN, fallait pas raconter n'importe quoi (et entre autres faire croire à coup de cravattes et costumes que le concept de VM était révolutionnaire alors que ça existait depuis des décennies...).
Ceci dit tu as raison il y a plein de JVMs pour de nombreuses plateformes, mais avec cette nouvelle version 1.5, toutes celles qui ne disposent que du 1.4 vont à nouveau être à la bourre, et on repart pour un cycle où seules celles officiellement supportées par SUN ou IBM seront à la page.
C'est dommage.
Ceci dit je ne désespère pas de me remettre à Java un jour, faut pas dramatiser 8-)-
[^]Re: révolutionnaire !
Posté par Stéphane TRAUMAT (page perso, ) le 04/10/2004 à 09:54. (lien). Évalué à 3.WORA... signifie que tu peux développer sur n'importe quelle plateforme ( style moi sous linux ) et déployer sans soucis sur n'importe quelle autre ( comme moi sous windows ).
Bien sur, il faut une JVM et je pense que personne n'a été assez naif pour croire que ca marcherait partout, sur tout et pour toujours...
mais avec cette nouvelle version 1.5, toutes celles qui ne disposent que du 1.4 vont à nouveau être à la bourre
Enfin, ca, vieux, c le jeu de l'évolution... tu gueules quand même pas quand un nouveau noyau linux sort et qu'il est pas aussitot dans les distribs ? faut du temps.-
[^]Re: révolutionnaire !
Posté par Yusei (page perso, ) le 04/10/2004 à 09:59. (lien). Évalué à 4.«Enfin, ca, vieux, c le jeu de l'évolution [...] faut du temps.»
Petite erreur de raisonnement, que l'on retrouve dans cette blague éculée où Toto, 6 ans vient d'apprendre que son grand-père a 86 ans. Comme il a aussi appris les soustractions récemment, il fait un petit calcul, et conclut tout joyeux que dans 80 ans, il aura le même âge que son grand-père.
Pour les gens en manque de café, je traduit: les JVM alternatives ne seront jamais au même niveau que les JVM officielles tant que celles-ci continueront à évoluer.-
[^]Re: révolutionnaire !
Posté par Stéphane TRAUMAT (page perso, ) le 04/10/2004 à 10:02. (lien). Évalué à 2.pas du tout d'erreur de raisonnement...
1) L'évolution est "obligatoire" en informatique.. quand on s'arrete on meurt non ?
2) Pkoi est ce que les jvms alternatives ne seront jamais au nivo des jvm officielles ? je vois pas le rapport-
[^]Re: révolutionnaire !
Posté par Yusei (page perso, ) le 04/10/2004 à 10:10. (lien). Évalué à 3.Pourquoi Toto n'aura jamais le même âge que son grand père ? Parce que pendant qu'il grandit, son grand-père continue de vieillir aussi.
Pourquoi une JVM alternative sera toujours à la traîne par rapport à la JVM de Sun ? Parce que pendant qu'ils comblent les manques, Sun continue de développer sa JVM et son langage (Actuellement le niveau de portabilité maximal c'est plutôt Java 1.1 que Java 2+).-
[^]Re: révolutionnaire !
Posté par Stéphane TRAUMAT (page perso, ) le 04/10/2004 à 10:26. (lien). Évalué à 2.Pourquoi une JVM alternative sera toujours à la traîne par rapport à la JVM de Sun ? Parce que pendant qu'ils comblent les manques, Sun continue de développer sa JVM et son langage (Actuellement le niveau de portabilité maximal c'est plutôt Java 1.1 que Java 2+).
Je ne suis pas d'accord.. les specs sont en libre accès et les jvm alternatives peuvent avoir les informations au même moment que sun.. donc à partir de la, ils pourraient très bien ne pas avoir de retard...
Sauf le fait que sun a plus de monde dessus.-
[^]Re: révolutionnaire !
Posté par Yusei (page perso, ) le 04/10/2004 à 10:31. (lien). Évalué à 0.La situation serait peut-être égale si tous les deux partaient de zéro, mais étant donné qu'ils ont du retard maintenant, il faudrait avoir plus de développeurs que Sun pour rattraper ce retard.
Effectivement, dans ma blague sur Toto, si Toto arrive à vieillir plus vite que son grand-père ça résoud le problème... mais ça semble difficile dans l'état actuel des choses.-
[^]Re: révolutionnaire !
Posté par Stéphane TRAUMAT (page perso, ) le 04/10/2004 à 10:37. (lien). Évalué à 4.ok... donc
Petite erreur de raisonnement, que l'on retrouve dans cette blague éculée où Toto, 6 ans
Il n'y avait pas d'erreurs dans mon raisonnement mais dans le tien
La situation serait peut-être égale si tous les deux partaient de zéro, mais étant donné qu'ils ont du retard maintenant, il faudrait avoir plus de développeurs que Sun pour rattraper ce retard.
C'est comme pour tout et je n'ai pas besoin de blague pour te le montrer.. quand quelqu'un part avant, il a plus d'avance que celui qui part après ! et oui !
je pense qu'il a fallu aussi quelques années à linux pour rattraper les unix.
et donc ta phrase : les JVM alternatives ne seront jamais au même niveau que les JVM officielles tant que celles-ci continueront à évoluer. était fausse.. "ne seront jamais" n'est pas juste. C'est possible.-
[^]Re: révolutionnaire !
Posté par Yusei (page perso, ) le 04/10/2004 à 10:48. (lien). Évalué à 0.Tu persistes et j'ai 5 minutes pour te répondre, pas facile ;)
Pour résumer l'idée: lorsque je dois faire un choix d'une techno, je me fiche royalement de savoir si dans un monde idéal qui n'existe pas, une techno est acceptable comme choix. Ce qui m'intéresse, c'est de savoir si dans le monde réel, cette techno est acceptable.
«et donc ta phrase : les JVM alternatives ne seront jamais au même niveau que les JVM officielles tant que celles-ci continueront à évoluer. était fausse.. "ne seront jamais" n'est pas juste. C'est possible.»
Je n'est pas dit "c'est impossible, dans aucun univers parallèle ça n'arrivera", j'ai dit "ça n'arrivera pas", sous entendu dans notre Univers. Ça pourrait arriver dans un monde où il y a plus de développeurs dans l'équipe du libre que dans celle de Sun, mais quelle pertinence pour choisir une techno dans notre monde ?
Je maintiens donc ma comparaison, Toto ne vieillit pas plus vite que son grand père, et les JVM libres n'évoluent pas plus vite que celle de Sun. Par conséquent, je ne suis pas prêt de voir une JVM libre au niveau de celle de Sun.
«je pense qu'il a fallu aussi quelques années à linux pour rattraper les unix.»
Les unix étant pour la plupart des gros dinosaures qui n'évoluent pas énormément, non ?-
[^]Re: révolutionnaire !
Posté par Stéphane TRAUMAT (page perso, ) le 04/10/2004 à 12:20. (lien). Évalué à 3.Ce qui m'intéresse, c'est de savoir si dans le monde réel, cette techno est acceptable.
Ce n'était pas ton propo au début mais admettons... dans le monde réel, java est utilisé pour tout et par beaucoup de gens.
je suis content de voir que tu dises Par conséquent, je ne suis pas prêt de voir une JVM libre au niveau de celle de Sun.. ca change de ton les JVM alternatives ne seront jamais au même niveau que les JVM officielles
Euh d'après toi ? combien d'années il a fallu à linux pour passer de statut d'embryon à celui "d'équivalent" Unix ?-
[^]Re: révolutionnaire !
Posté par Yusei (page perso, ) le 04/10/2004 à 16:26. (lien). Évalué à 2.«Ce n'était pas ton propo au début mais admettons.»
C'était quoi mon propos alors ?
«je suis content de voir que tu dises Par conséquent, je ne suis pas prêt de voir une JVM libre au niveau de celle de Sun.. ca change de ton les JVM alternatives ne seront jamais au même niveau que les JVM officielles»
Si ton contentement porte sur le fait que j'ai dit libre au lieu de alternative, j'admet que je n'avais pas été précis au début... Sinon, je ne vois pas ce que tu veux dire. Je maintiens exactement la même chose depuis le début (à cette imprécision prêt): en pratique, on doit utiliser une JVM non libre pour exécuter un programme Java récent, et ce n'est pas pret de changer.
«combien d'années il a fallu à linux pour passer de statut d'embryon à celui "d'équivalent" Unix ?»
Unix était un concept stable quand Linux est apparu, ça suffit à invalider toute comparaison. J'veux bien en discuter quand même, mais les questions rhétoriques c'est assez lourd, il faut deviner soi même l'argument... Tu veux dire que si on attend encore deux ou trois ans, les JVM libres seront au niveau de celle de Sun ? Mais laquelle, de Sun ? Au niveau de Java 1.5, ou au niveau de la version de Java de dans deux-trois ans ?-
[^]Re: révolutionnaire !
Posté par √λιi () le 04/10/2004 à 17:19. (lien). Évalué à 3.Je vais m'insérer dans cet discution privée et dire :
1) - La vitesse de développement se mesure en temps*homme, avec quelques corrections d'échelles (ressources matérielles, qualité des dévelloppeurs, etc ...).
2) - Si la mesure temps*homme global d'un projet 1 est supérieur à celui d'un autre projet 2 (demandant la quantité de tavail comme une JVM, par exemple), alors le dévellopement du projet 1 ira plus vite (le nombre de fonctionnalité implémentées dans un même laps de temps pour le 1 sera supérieur au 2).
3) - quelque chose qui va plus vite qu'une autre, est soit devant, soit ratrapera l'autre en un temps fini.
4) - Sachant 1, 2,3, une JVM develloppé par un tiers peu rattraper la JVM de Sun.
Mais il y a des restrictions à ce raisonnement pour le placer dans un raisonnement de faisabilité :
1) - la quantité de dévellopeur sur une JVM alternative dépends de la demande des utilisateurs, + ou -.
2) - sun peu augmenter le temps*homme pour le dévellopement de java, dont l'un des critère peu être la quantité d'utilisateurs.
3) - La réécriture demande à réinventer la roue, et parfois on doit la faire de manière différente. (pour contribuer au projet classpath, il ne faut SURTOUT pas s'inspirer des sources du Java de sun, c'est l'une des première choses qu'il imposent aux contributeurs)
4) - et bien d'autre ....
Ceci pour dire : nous vivons dans un monde réel, qui a ses contraintes, et que je sache, les dévellopeurs de sun seront toujours d'un nombre fini.
Le modèle de dévellopement habiltuel du libre permet d'avoir un très grand nombre de dévelloppeurs sans comprommettre le projet, alors que dans le monde de l'entreprise le modèle de dévellopement peu s'avérer invalide si l'on a trop de ressources humaines (problèmes de communication, et autres ...). Certaines entreprises on planté des projets à causes de problèmes d'organisation !
Ceci implique que faire un JVM libre du niveau de celle de sun est *possible*.-
[^]Re: révolutionnaire !
Posté par Yusei (page perso, ) le 04/10/2004 à 17:45. (lien). Évalué à 2.(ce n'est pas une discution privée, et ça fait du bien de voir une bonne argumentation. Je précise ma pensée une dernière fois parce que j'ai des Xp à perdre ;)
Ma formulation de départ laissait penser que je disais que c'était impossible dans l'absolu, je le reconnais, mais nous avons éclairci ce point dans la suite de la discution. Je suis d'accord que c'est théoriquement possible, et ma comparaison n'est évidemment valide que parce que les équipes de développement de JVM libres n'évoluent pas plus vite que celle de Sun. Mais je maintiens qu'elle est valide à cause de ça, et que c'est un obstacle important à la portabilité.
-
-
-
[^]Re: révolutionnaire !
Posté par Yusei (page perso, ) le 04/10/2004 à 17:11. (lien). Évalué à 2.Ah, j'avais oublié de lire un passage
«dans le monde réel, java est utilisé pour tout et par beaucoup de gens.»
Dans le monde réel, une écrasante majorité de gens n'en a rien à faire de savoir si un logiciel est libre. Comme tu peux t'en douter, l'objection dont on parle ici (le fameux "java trap") ne leur est pas destinée.
Je vais quand même achever ma participation ici, parce qu'en relisant, j'ai compris ce que tu voulais dire en exprimant ton contentement. Tu fais une citation sélective de mes propos, pour me faire dire des conneries, ce qui clot la discution (je n'ai pas dit que les JVM alternatives ne seraient jamais au niveau des JVM officielles, j'ai dit que ce serait le cas tant que les JVM officielles continuerait d'évoluer en même temps).-
[^]Re: révolutionnaire !
Posté par nicolassanchez () le 05/10/2004 à 08:51. (lien). Évalué à 4.En gros, la solution pour que les JVMs soient vraiment portable serait l'ouverture du code par Sun, ce qui permettrait des portages pour les plateformes plus rares, et ça permettrait à tout le monde d'utiliser la même JVM...
-
[^]Re: révolutionnaire !
Posté par nooky59 () le 06/10/2004 à 19:20. (lien). Évalué à 1.Et d'après ce que j'ai lu dans le dernier Login qui parlait de la conférence JavaOne, les specs sont publiques et le code source de l'API et la JVM librement consultable.
Par contre, évidemment, çà ne doit pas être aussi libre qu'un projet sous GPL mais je ne connais pas les restrictions.
-
-
-
-
-
-
-
-
-
-
-
-
[^]Re: révolutionnaire !
-
-
-
[^]Re: révolutionnaire !
Posté par Yannick (page perso, ) le 04/10/2004 à 11:05. (lien). Évalué à 5.Je me joins aux réponses de ce commentaire, et je précise que contrairement a Perl, ils considèrent plus de choses que le simple fait que ça mache sur une parteforme pour dire qu'elle est supportée...
Et comparer la portabilité de Perl et de Java, c'est léger : ils ne jouent pas dans la même cour. C'est plus facile de traduite un "Perl précis et concis" de 100 pages en Urdu, que le "Larousse encyclopédique" en 5 volumes...
-
-
-
-
-
-
-
[^]Re: révolutionnaire !
Posté par Chaddaï Fouché () le 03/10/2004 à 14:03. (lien). Évalué à 7.Oui, il est certain que malgré le ton de la news, la lecture des nouveautés donne la forte impression que Sun a créé un Java/C(++) et clame qu'il s'agit d'une innovation révolutionnaire alors qu'un grand nombre d'argument de Sun visait auparavant à discréditer ces mêmes concept qu'ils remettent aujourd'hui dans leur langage... Assez surprenant je trouve même si les fanatiques de Java vont surement m'expliquer que si je trouve un goût C++ de plus en plus prononcé à Java c'est uniquement parce que je suis un parfait ignorant et que tous ces concepts sont des révolutions... Ah si, y a la boucle foreach qui est pas dans le C++ (encore que Qt propose une solution avec le préprocesseur qui mime parfaitement le comportement de ce type de boucle) même si dans le genre révolutionnaire on fait mieux (cf les langages de scripts comme Perl ou PHP par exemple qui ont ça depuis fort longtemps).
Vous aurez compris que je fais une allergie à Java, surtout ces derniers temps: Bien que je lui trouve effectivement des avantages objectifs (dans tous les sens du terme ;-) ), ce langage m'attire décidemment de moins en moins (d'autant plus qu'il semble actuellement perdre son âme, qui ne m'avait pas parue particulièrement originale pour commencer).
(J'attends le moinssage sauvage que ce troll ne manquera pas de provoquer :-) )
--
Jedaï-
[^]AHMA
Posté par _alex () le 03/10/2004 à 15:16. (lien). Évalué à 10.Ca n'a rien de révolutionnaire à mon goût : pour les types génériques ca me fait penser à ADA (j'ai plus fait d'ADA que de C++, ya peut être de ça). Il me semble d'ailleurs que beaucoup de fonctionnalité sont implémentées dans le compilateur et non pas dans la JVM.
Perso, j'apprécie ce langage, en fait les bibliothèques et les communautés autour y sont pour beaucoup.
En même temps, c'est vrai je n'ai pas beaucoup programmer en C++ ou en Python; et j'utilise java pour faire des traitements sur des données XML.
Note sur feature pas donné dans la news: la JVM ne recharge plus 2 fois le contenu classpath en RAM si on lance 2 JVM : http://java.sun.com/j2se/1.5.0/docs/guide/vm/class-data-sharing.htm(...)-
[^]Re: AHMA
Posté par nooky59 () le 06/10/2004 à 19:24. (lien). Évalué à 1.Et un avantage de Java qu'on ne peux nier, qu'on soit partisan ou pas est que des technologies émergantes ont bien souvent tendance à être implémenter en Java avant d'autres langages comme le C et le C++.
Par exemple, les APIs XML et les webservices.
-
-
[^]Re: révolutionnaire !
Posté par Croconux () le 03/10/2004 à 15:50. (lien). Évalué à 9.alors qu'un grand nombre d'argument de Sun visait auparavant à discréditer ces mêmes concept
En créant Java, les devs de Sun on voulu créé un langage simple à apprendre et débarassé des fonctionnalités dont l'utilisation complexe et souvent mal maitrisée conduit souvent dans le mur (heritage multiple, surcharges d'opérateurs).
Il se trouve que dans le monde merveilleux du logiciel certains sont fans des goodies qui pimentent la vie. Sun a trainé les pieds mais ils ont fini par plier.
-
[^]Re: révolutionnaire !
Posté par Romain Guy (page perso, ) le 03/10/2004 à 16:27. (lien). Évalué à 10.La plupart des nouveautés proviennent des JSR émises au sein du JCP. Lorsque j'avais interviewé James Gosling, l'un des pères de Java, au sujet de Java 5 il m'avait bien précisé qu'il n'aimait pas du tout l'autoboxing ou les generics.
Ces nouveautés sont donc la volonté de la communauté et non de Sun, qui se doit malgré tout de communiquer positivement à ce sujet, quel que soit leur avis.-
[^]Re: révolutionnaire !
Posté par gc (page perso, ) le 04/10/2004 à 07:52. (lien). Évalué à 7.Pourquoi n'aime-t-il pas l'autoboxing ?
Pour moi l'absence d'autoboxing de Java < 1.5 est une des pires tares du langages, j'aimerais vraiment connaître ses arguments.-
[^]Re: révolutionnaire !
Posté par Cook Captain () le 04/10/2004 à 20:05. (lien). Évalué à 4.Pour pleine de bonnes raisons.
* En fait l'autoboxing peut entrainer des trucs bizarres :
public int compute(int a, int b) {
return a+b ;
}
Qu'est ce qui se passe quand tu fais :
Integer AA = new Integer(1) ;
Integer BB = null ;
int sum = compute (AA, BB) ;
Tu auras un null pointer exception sur une methode qui ne comporte que des types primitifs !!!
* De plus l'autoboxing peut entrainer des pb de perfs assez conséquent si on n'est pas vigilant. (création et destruction d'objets).
Bref moi non plus je ne suis pas un fan...-
[^]Re: révolutionnaire !
Posté par tene (page perso, ) le 04/10/2004 à 21:11. (lien). Évalué à 2.Donc il faudrait:
- Des types "valeurs", qui ne pourrait être null... même si ça ressemble à une classe (et au passage faire que le boxing/unboxing soit un peu plus qu'un jeu syntaxique, genre que ça permette d'optimiser le brol...)
Et puisqu'on est gentil, des nullable type quand même, parce qu'on a assez chié en ramant sur les valeurs nulles de notre SGBD favori...
Mouais ce serait pas mal d'avoir un langage avec ça :p
-
-
[^]Re: révolutionnaire !
Posté par reno () le 04/10/2004 à 21:32. (lien). Évalué à 2.Je pense que c'est le coté "caché" de la chose qu'il n'aime pas..
L'autoboxing masque les conversions ce qui rend le code beaucoup plus lisible, mais d'un autre coté les conversions ont un cout en perf qui n'apparait plus maintenant..-
[^]Re: révolutionnaire !
Posté par TImaniac (page perso, ) le 05/10/2004 à 16:32. (lien). Évalué à 2.C'est un peu le problème de l'autoboxing : il faut plus ou moins réfléchir avant de l'utiliser, le problème c'est qu'on ne s'en rend pas toujours compte. Heuresement, l'impact sur les perfs est négligeable, sauf dans les boucles... J'ai un peu du mal à expliquer parfois à des programmeurs qu'il faut parfois l'éviter :)
M'enfin chez Sun ils sont tellement doués qu'ils sont eux même tombé dans le panneau : avec leur implémentation des generics, tout type primitif se vera boxé et déboxé lorsque associée à une classe générique... comme quoi.
-
-
-
[^]Re: révolutionnaire !
Posté par boubou (page perso, ) le 04/10/2004 à 08:39. (lien). Évalué à 1.Sun a un droit de veto dans le JCP, donc si Sun n"avait pas voulu de l'autoboxing, il n'y en aurait pas eu. Il ne faut pas confondre Sun et Gosling.
-
-
[^]Re: révolutionnaire !
Posté par Stéphane TRAUMAT (page perso, ) le 03/10/2004 à 16:33. (lien). Évalué à 3.Moi, je ne vois que deux trois fonctionnalités du C et du C++... on est quand même très loin de ça... On a toujours pas de pointeurs, on a un garbage collector, une API commune, une machine virtuelle.... vous allez quand meme pas dire que Java est proche du C / C++.
On a ajouté un certain nombre de choses de C+C++ mais surtout de C# à mon avis.
Mais c'est la vie.. l'informatique évolue très vite et si les gens ont des idées, pkoi ne pas les utiliser ? les choses changent.
Ce qui me ferait vraiment chier perso, c'est de programmer dans des langages qui n'évoluent pas et qui ne reprennent pas le meilleur de ce qui se fait à un instant t.-
[^]Re: révolutionnaire !
Posté par TImaniac (page perso, ) le 04/10/2004 à 11:09. (lien). Évalué à 4.l'informatique évolue très vite et si les gens ont des idées, pkoi ne pas les utiliser ?
Justement, et je trouve dommage que Sun, pourtant dans une position très favorable, n'en profite pas pour justement faire germer des idées : non là ils se contentent de copier, et laisse les autres innover. C'est pas vraiment grâce à celà que l'informatique va évoluer, rien ne vaut l'innovation.-
[^]Re: révolutionnaire !
Posté par Stéphane TRAUMAT (page perso, ) le 04/10/2004 à 12:23. (lien). Évalué à 3.Ils ne font pas que copier.. les métas data tels qu'ils les utilsent, ca vient quand même beaucoup de XDoclet qui est une innovation du monde Java...
et puis, inventer des nouvelles choses dans les langages, tu fais pas ça tous les jours.. je suis à peu près sur que tout existe dans l'ensemble des langages ;)
Et oui, ce JDK est une innovation et oui, java fait évoluer l'informatique-
[^]Re: révolutionnaire !
Posté par TImaniac (page perso, ) le 04/10/2004 à 16:17. (lien). Évalué à 2.inventer des nouvelles choses dans les langages, tu fais pas ça tous les jours..
Pourtant certaines boîtes ont un secteur R&D et développe des nouveaux concepts, parfois tirés d'autres concepts mais dans l'innovation il y a aussi le fait de réussir à intégrer des technos du passé...
Et oui, ce JDK est une innovation
dans le monde Java uniquement.
et oui, java fait évoluer l'informatique
De part sa communauté et des produits qui sont créés avec. Mais cette version de Java en soit de fait rien progresser du tout. Je dirais même que leur implémentation des generics va plutôt limiter dans le futur, parcque ce genre de choix est difficilement modifiable. Mais fallait sortir vite fait leur produit, sans faire de gros effort de R&D alors bon...-
[^]Re: révolutionnaire !
Posté par Cook Captain () le 05/10/2004 à 21:56. (lien). Évalué à 2.> jedirais même que leur implémentation des generics
> va plutôt limiter dans le futur
Une implémentation n'est jamais gravée dans la pierre. Comme l'a fait C#, cela obligera à un changement du bytecode.-
[^]Re: révolutionnaire !
Posté par TImaniac (page perso, ) le 06/10/2004 à 05:51. (lien). Évalué à 2.Euh, une implémentation comme celle-ci est forcement gravée dans la pierre, parcque là Sun n'a pas juste choisi une implémentation, il a aussi choisi une sémantique associée aux generics... ca ne se modifie pas comme celà, au risque de tout voir péter.
-
[^]Re: révolutionnaire !
Posté par Cook Captain () le 06/10/2004 à 08:36. (lien). Évalué à 2.Non, pas dans ce cas la. Une implémentation des génériques à la C# entrainerait, je l'ai déja dit un changement de byte code, (comme cela a été le cas pour C#) mais pas d'incompatibilté majeure.
-
[^]Re: révolutionnaire !
Posté par TImaniac (page perso, ) le 06/10/2004 à 10:52. (lien). Évalué à 2.Si si je t'assure, celà changerai aussi la sémantique, notamment à l'exécution : un programme qui fait de l'introspection ne verra pas du tout la classe de la même manière selon l'implémentation choisie. Si celà ne posait pas de problème d'incompatibilité majeure, alors pourquoi ils n'ont pas choisie l'implémentation de C# ?
-
[^]Re: révolutionnaire !
Posté par Cook Captain () le 06/10/2004 à 15:04. (lien). Évalué à 2.Dans le cas de l'introspection tu aurais une classe dérivée au lieu de ta classe de base. Je ne pense pas que cela soit bien grave...
Il ne l'ont pas choisi car Sun ne voulait pas changer son bytecode comme l'a fait Microsoft. De toute manière, changer le byte code casse beaucoup plus de choses. En tout état de cause, je ne sais pas si c'est un bon choix car de tout manière, il faudra bien qu'un jour le byte code évolue.-
[^]Re: révolutionnaire !
Posté par TImaniac (page perso, ) le 06/10/2004 à 16:03. (lien). Évalué à 2.Dans le cas de l'introspection tu aurais une classe dérivée au lieu de ta classe de base.
Non non, à l'exécution tu auras une classe avec comme paramètre object... youpi.
Effectivement celà apporte une modification au niveau de la JVM : ajouter une notion aux types. M'enfin la solution de Microsoft le fait, et les anciens programmes marchent très bien sur la nouvelles VM. Evidemment l'inverse n'est pas possible... Mais bon là ils ont pété le langage en y ajoutant des modifs qui casse tous les compilateurs : ils auraient pu en profiter pour faire pareil sur la JVM... Franchement ils n'ont à mes yeux aucune excuse sur ce coup.
-
-
-
-
-
-
-
-
-
[^]Re: révolutionnaire !
Posté par mdlh () le 04/10/2004 à 14:15. (lien). Évalué à 2.on a un garbage collector
Pour le C et le C++: http://www.hpl.hp.com/personal/Hans_Boehm/gc/(...)-
[^]Re: révolutionnaire !
Posté par Stéphane TRAUMAT (page perso, ) le 04/10/2004 à 14:20. (lien). Évalué à 2.AH serait ce le moment de dire "ouais, C++ , ca va devenir du java.. on va enfin pouvoir faire des trucs concrets avec... " :)
Mais non :)-
[^]Passez à l'Objective-C !!!
Posté par nicolassanchez () le 05/10/2004 à 09:20. (lien). Évalué à 4.Passez à l'Objective-C, c'est surpuissant et ultra simple...
En effet, il n'y a pas dix milliards de mots clefs à ajouter (y'a pas de abstract, virtual, etc.).
Tu gardes tous les avantages du C, la gestion de mémoire se fait à l'aide de compteur de références que tu incrémente et décrémente à la main (ou avec un garbage collector de ton choix si tu le souhaites), tu fais de l'objet distribué ultra facilement...
Contrairement au C++, l'Objective-C a un Runtime comme le Java ou le C#... en gros tu peux modifier tes classes pendant l'exécution...
Grâce à GNUstep, l'objective-C et OpenStep devient compatible entre tous les systèmes après recompilation (sur MS pas tout à fait mais très bientôt...). Avec GNUstep, il sera bientôt possible de mêler du C++ avec de l'Objective-C dans le même fichier...
Pour ne rien oublier, l'accès aux bases de données se fait à l'aide de EOF ou avec du SQL standard...
GnustepWeb est une implémentation de WebObjects qui repose sur GNUstep...
C'est vrai qu'il faut recompiler selon le système, mais bon, il y a gnustep-make qui rend l'opération extrêmement facile...
En gros, avec GNUstep et ses petits copains, tu peux tout faire, facilement et très proprement...
-
-
-
-
[^]Re: révolutionnaire !
Posté par RuleZ () le 03/10/2004 à 16:34. (lien). Évalué à 6.Je vais me risquer à essayer de résumé l'intérêt de Java en rapport à ses spécificités de base :
- Le language en lui même est pure objet, java est né objet, et ça c'est ce qui en fait un language d'un immense intérêt pour les développements d'applications. Petit rappel : L'orienté objet offre la possibilité d'architecturer, d'étendre, et d'entretenir à merveille une application pour peu que sa conception ai su profiter de l'objet, et que le language en permette une mise en oeuvre aisé .. Java répond à tous les besoin d'un developpeur d'applications en matiére de conception objet.
- La plateforme Java/J2EE, standart, extrémement compléte, sans aucune lacune. Pour un développement applicatif c'est idéal : on se concentre sur l'algorithmie, sur l'architecture de nos objets et leurs routines de base, sur de l'assemblage basique de composants et d'objets ... On n'a pas à passer des heures à réécrire des fonctions de gestion d'un bout d'interface, de traitement d'entrées/sorties, on a déja tout à porté de main, chaque développeur ne réinvente pas la roue dans son coin, chacun se concentre sur ce qui différencie réellement son application d'une autre, en utilisant les objets fournis en standart avec la plateforme, et on n'a pas à réécrire une banale routine déja écrite un million de fois par un millions d'autres développeurs.
- La machine virtuelle : qui, dans un monde utopique, offrirai la portativité absolue, puisque c'est le code compilé lui-même qui peut s'éxécuter sur des OS différents, sur du matos différent (dans un monde ou Microsoft n'a pas encore réussi sa tentative d'hégémonie), sans que le développeur n'ait à se préoccuper des milliers de petites différences qui pourraient bouleversé l'éxecution de son application.
Résumé: Java ce n'est pas seulement un language, c'est aussi et surtout une plateforme et une machine virtuel.-
[^]Re: révolutionnaire !
Posté par Stéphane TRAUMAT (page perso, ) le 03/10/2004 à 16:45. (lien). Évalué à 2.Perso, l'objet m'interesse sutout pour masquer la complexité des traitements et la réutilisation.
Je préfère faire un commande.ajouterArticle(article); à des sales inserts sql ;)
Et j'ajouterais que la jvm et J2ee sont définis par JCP dont sun est un membre comme BEA, JBoss ou Gavin King.
-
[^]Re: révolutionnaire !
Posté par Yusei (page perso, ) le 03/10/2004 à 17:12. (lien). Évalué à 9.«Le language en lui même est pure objet»
T'en as d'autres des énormités pareilles ? Java est orienté objet, il n'est pas pur objet. Il n'y a qu'à voir les types de base qui ne sont pas des objets. Ils commencent tout juste à masquer la différence entre un type de base et un objet dans cette version, qui permet si j'ai bien compris un cast implicite de int vers Integer, etc.
"Petit rappel" pour moi aussi, dans un langage pur objet, tout est un objet, par exemple ceci est valide:
(2 + 3).to_string()
Dans les langages "presque pur objet", il y a l'Eiffel, dont on a parlé ici récemment, il y a le Ruby aussi, que je recommende à tout le monde. Je crois que Smalltalk est complètement objet, mais je n'ai jamais vérifié par moi même.-
[+] [^]Re: révolutionnaire !
Posté par RuleZ () le 03/10/2004 à 18:29. (lien). Évalué à -5.Enormité ? Pas vraiment, peut-être que oui pour les puristes, mais pour moi ce n'était juste qu'une simple hyperbole servant à appuyer mes propos.
Pour te déstresser, sache donc que j'avais parfaitement conscience de mon abus de language (à la limite), qui m'évitais juste de partir trop en vrille en digressant excessivement sur ce que n'est pas java.
Ce que mon "pure" associé à "objet" signifié implicitement, ce n'était pas que dans java tout est objet, mais plutot que rien dans java n'est procédurale, contrairement à un certains C++.
-
[^]Re: révolutionnaire !
Posté par celastus () le 03/10/2004 à 22:18. (lien). Évalué à 9.Smalltalk est completement objet. Tout ce qu'on pouvait manipuler aves Smalltalk était indirectement instance d'une sous classe de Object : les entiers, les classes, les métaclasses, les booléens (true et false sont les deux instances uniques de la classe Boolean), l'objet vide, nul (instance de la class Null)...
Je ne connais pas de langage qui soit autant "objet" que smalltalk, à part peut-être certaines implémentations en lisp à l'interêt principalement éducatif.
Smalltalk est un tres, tres beau langage avec lequel j'ai pu m'amuser en entreprise il y a quelques années. Cela fait bien longtemps que je ne l'ai pas vu tourner. Je ne sais même pas s'il est encore mis à jour.
Les problemes de smalltalk étaient les suivants :
- Les concepts de l'interface graphique (MVC - Modele vue contrôleur) étaient tres puissants mais difficiles à apprehender
- Le systeme de classe étais un peu complexes pour un débutant. Chaque classe créée par le développeur donnait lieu à la création se sa méta-classe. La classe Collection était instance de la metaclass "class Collection". La classe Object Class étais sous-classe de la classe Metaclass, elle-même indirectement sous-classe de Object (comme toutes les classes de smalltalk). Comme vous voyez ce n'est pas simple...
- La machine virtuelle prenait beaucoup de mémoire. Elle incluait un environnement de développement, un débogeur et ln compilateur, tout tres tres bien faits mais gourmands...
- Le typage statique est inexistant ou presque. Ce n'est qu'à l'execution que la machine virtuelle peut détecter qu'une methode appellée n'existe pas. Pour couronner le tout, il est possible de faire de la meta-programmation, et d'appeller une méthode par son nom. Il n'est alors même plus possible en regardant le code de savoir quelle est le nom de la méthode appellée...
Le compilateur, comme tout l'environnement de développement, étais écrit en Smalltalk. Il produisait du code-ocyet (bytecode) interpreté par une machine virtuelle, coeur de l'architecture smalltalk. Les methodes primitives étaient les seules méthodes ne contenant pas de code smalltalk, et faisaient directement appel à la machine virtuelle. Par exemple, la méthode + de la classe Integer, ou les méthodes de bas niveau ayant trait à l'interface graphique.
Le concept de fermeture si cher à Lisp existait dans smalltalk. Ainsi le bloc [:x :y | (x>y) itTrue: [x] ifFalse: [y]] prends en entrée deux nombres et en renvoie le plus grand. Notez la méthode ifTrue:ifFalse, implementée dans la classe Boolean, qui prends deux blocs sans arguments en entrée et execute l'un ou l'autre selon la valeur de l'objet courant (self). Notez aussi que ce type de code est totalement générique : tant que la classe dont l'objet x est instance implémente la méthode >, accepte y comme argument, et renvoie un booléen, le code fonctionnera.
Les apples de méthodes étaient evidemment tous résolus dynamiquement, il n'étais pas question comme en c++ de devoir déclarer qu'une méthode était virtuelle. Toutes les méthodes étaient virtuelles sans exception. Les méthodes de type static étaient implémentées comme des méthodes standard dans la métaclasse. Par exemple, la méthode new de la classe "class Table" renvoyait une instance de la classe "Table", non sans lui avoir envoyé le message init (i.e. appellée la méthode init sur cet objet).-
[^]Re: révolutionnaire !
Posté par _alex () le 03/10/2004 à 23:15. (lien). Évalué à 3.Je trouvais ce langage assez génial pour le concept "tout est objet" (pour ajouter le foreach de java, ce n'est pas bien long et modification du compilateur, de la VM ou autre). Par contre il y a une chose qui m'avait supris :
J'ai appris ce langage à l'université, on a eu un TP à faire. 5 min avant de faire la démo un groupe avait un bug, partout ou il devait utiliser "<" il utilisait ">". Solution d'un des élève : patcher le code Integer, méthode "<" , pour que le programme marche.
Il y a peu d'autre langage ou c'est possible ;-)
(Je trouvais la création d'interface utilisateur assez sympa)-
[^]Re: révolutionnaire !
Posté par celastus () le 04/10/2004 à 10:30. (lien). Évalué à 1.Patcher la méthode < de la classe Integer, c'est rigolo, mais ça risque quand même de faire planter tout le reste du code, y compris le code des classes smalltalk existantes.
Par contre, il y avait un truc que j'aimais bien faire : patcher la méthode d'affichage graphique des caracteres pour les afficher à l'envers (comme dans un miroir). A peine la méthode validée, toute l'interface graphique de smalltalk, du gestionnaire de classes au débogueur, était affichée à l'envers.
-
-
[^]squeak
Posté par zebul666 () le 04/10/2004 à 08:52. (lien). Évalué à 2.j'ai entendu parler de squeak. comme un petit-fils de smalltalk ? non ?
http://www.squeak.org(...)
-
-
[^]Re: révolutionnaire !
Posté par lorill (page perso, ) le 04/10/2004 à 07:30. (lien). Évalué à 1.Et groovy ! http://groovy.codehaus.org(...)
-
[^]Re: révolutionnaire !
Posté par gc (page perso, ) le 04/10/2004 à 07:54. (lien). Évalué à 2.Pourquoi "presque" pour Ruby ?
-
[^]Re: révolutionnaire !
Posté par Yusei (page perso, ) le 04/10/2004 à 08:22. (lien). Évalué à 2.Il y a certaines choses dans Ruby qui ne sont pas des objets, comme les structures de contrôle ou (je crois) les classes. C'est suffisant pour qu'il ne soit pas pur objet, mais il en est assez proche pour que ça ne m'ait jamais dérangé.
-
[^]Re: révolutionnaire !
Posté par gc (page perso, ) le 04/10/2004 à 10:09. (lien). Évalué à 2.Les classes sont des objets suivant cette démo (ou alors je n'ai pas compris le principe) :
irb(main):001:0> i = 1
=> 1
irb(main):002:0> i.class
=> Fixnum
irb(main):003:0> i.class.class
=> Class
Pour les structures de contrôle je ne savais pas que ça pouvait/devait être des objets aussi, ça doit être parce que j'ai raté la case Eiffel :/
En quoi est-ce utile ? Enfin je veux dire, quelle chose jolie on peut faire en Eiffel (ou autre) grâce au fait que les structures de contrôle sont des objets, que l'on ne peut pas faire en Ruby ?-
[^]Re: révolutionnaire !
Posté par Yusei (page perso, ) le 04/10/2004 à 10:22. (lien). Évalué à 2.Oui, pour les classes je me suis trompé, c'est peut-être les méthodes qui n'en sont pas, faudra que je vérifie où j'avais trouvé cette idée (fausse :).
Je ne crois pas qu'en Eiffel les structures de contrôle soient des objets, mais Eiffel n'est pas pur objet (selon les définitions que l'on prend, les opinions diffèrent).
Pour le fait que ça puisse être des objets, étant donné qu'en Ruby un bloc de code est un objet, on peut voir une struture for comme un objet défini par:
- Le bloc de code d'init
- Le bloc de test
- Le bloc «d'incrémentation»
- Le bloc à effectuer à chaque itération.
Ce n'est pas spécialement intéressant tel quel, sauf si on veut pouvoir modifier un des blocs au vol. Par contre on peut imaginer quelques applications à l'héritage sur une structure de contrôle, j'en prend une complètement bidon:
J'ai un "while" qui attend une connexion, effectue un dialogue, et boucle. Je voudrais modifier cette boucle pour effectuer un calcul au début de chaque itération. Je peux redéfinir l'object "while" pour rajouter cette fonctionnalité à toutes les boucles.
Un peu plus intéressant, je peux avoir deux versions d'un objet While, une avec des opérations de débug, et l'autre sans. Lors de l'exécution, je définis celle qui m'arrange en fonction des arguments donnés.-
[^]Re: révolutionnaire !
Posté par TSelek () le 04/10/2004 à 11:19. (lien). Évalué à 0.Ben en ruby les methodes aussi sont des objets, des "chuncks", de la classe Proc.
par contre, "def", "if" etc ne sont pas des objets (quoique... ça ne serait pas des méthodes en elles-mêmes?...) mais bon, en arriver à savoir si le ';' est un objet, heing...
-
-
-
-
-
-
[^]Re: révolutionnaire !
Posté par Miguel Moquillon (page perso, ) le 04/10/2004 à 08:43. (lien). Évalué à 4.Hum ... Smalltalk ?
Bon, soyons sérieux, l'informatique est un eternel recommencement.
On dit que si on veut voir l'informatique dans le futur, jetons un coup d'oeil à Smalltalk. Je pense que ce n'est pas loin d'être vrai.
Ce que l'on a sous la main, on se dit super ! et on se précipite à le refaire, différemment, évidamment, pour finalement, peu à peu, introduire de nouvelles caractéristiques qui lui font peu à peu ressembler à l'original mais ... pas en mieux. J'aime bien la diversité, mais je n'aime pas ce qui essaie de copier en moins bien l'original.
Par exemple, j'aime bien Ruby/python, Self, Eiffel pour leur apport et différentiation.
Vous aimez les caractéristiques de Java 5 ou de C# ? Regardons de côté d'Eiffel par exemple pour s'appercevoir que finalement ce n'est pas si révolutionnaire que ça. Autant Java, langage des années fin 90, a les circonstances atténuantes, autant C#, apparue au 21e siècle, n'a aucun pardon pour être aussi "pauvre" comme langage dit objet ; mais bon, faut pas se leurrer, ce sont avant tout des langages commerciaux.
Vous aimez le principe de la VM, regardons du côté de Smalltalk (et aussi pour toutes ses caractéristiques) et là vous commencez à pleurer de vous tapper ces merdes (pardon pour ce gros mot) que l'on appelle JVM (essayer squeak et je pense que vous comprendrez).
ha, l'API de Java ? Lorsqu'on l'a compare à celui de Smalltalk ou d'OpenStep, vous commencez à mettre en doute les compétences réelles en objet des concepteurs de cette API Java (oui, je sais, j'y vais un peu fort). Enfin bref, une API de qualité différente, non cohérente sur l'ensemble des composants. Mais bon, nul n'est parfait et Java (il n'est pas le seul) l'illustre parfaitement :)
Bon, bref. Ce que je peux dire, c'est que Java 5 n'est pas une révolution, mais une simple évolution qui va, enfin, me permettre de programmer correctement, avec une certaine souplesse et à prendre enfin plaisir à programmer avec ce langage.-
[^]Re: révolutionnaire !
Posté par TImaniac (page perso, ) le 04/10/2004 à 11:12. (lien). Évalué à 2.Autant Java, langage des années fin 90, a les circonstances atténuantes, autant C#, apparue au 21e siècle, n'a aucun pardon pour être aussi "pauvre" comme langage dit objet
En quoi C# est-il pauvre ?-
[^]Re: révolutionnaire !
Posté par Miguel Moquillon (page perso, ) le 04/10/2004 à 12:16. (lien). Évalué à 5.Quelques exemples :
- pas de généricité contrainte. Permet de rajouter de la flexibilité à des langages à typage statique, de pouvoir faire de l'objet selon l'appoche F-Bound et non celle, plus limitée, de Liskov.
- pas de covariance. Du moins avec les types de retour des méthodes, car celle des arguments est plus problématique sauf si il y a support des types ancrés, auquel cas on peut faire là aussi de l'objet selon l'approche F-Bound.
- plus discutable : pas de visibilité flexible (telles methodes ne sont visibles que par les objets de telle et telle autre classe)
- etc.
Je ne mettrait pas ici l'héritage multiple, même si, depuis la fin des années 80, on sait correctement la gérer (pas comme C++ ou c'est pitoyable). Ca dépend si le langage veut se faire simple ou non.
De même je n'introduit pas non plus la faculté de définir des méthodes supplémentaires à une classe existante ou mieux à des objets ; ceci permet une utilisation souple du concept de rôle.
Ce n'est que quelques exemples, mais les deux points ci-dessus sont, AMHA, les plus importants que devrait supporter un langage objet à typage statique moderne.-
[^]Re: révolutionnaire !
Posté par TImaniac (page perso, ) le 04/10/2004 à 16:26. (lien). Évalué à 2.pas de généricité contrainte.
Tu peux expliquer ?
pas de covariance.
L'utilisation qui est généralement faite de la covariance peut tout à fait être envisagé par les arguments de méthodes passés en référence. Même si il n'y a pas de covariance, il n'y a pas de limitation, puisque le but peut être atteind autrement.
pas de visibilité flexible
Alors là c'est vraiment discutable.
Il suffit d'avoir une interface I qui contient une méthode foo, alors la classe A :
class A : I {
I.foo();
}
la méthode foo n'est accessible que lorsqu'elle est référencé en tant que I. Celà permet de gérer proprement les accès aux objets utilisateurs en leur filant seulement l'interface désirée.
Je ne mettrait pas ici l'héritage multiple
Même si leur implémentation est tout à fait envisageable, il y a de nombreuses raisons de s'en passé (d'abord parcque ce n'est pas indispensable).
De même je n'introduit pas non plus la faculté de définir des méthodes supplémentaires à une classe existante ou mieux à des objets
Ce concept peut très bien envisager avec une méthode orientée aspect et un tissage sur des classes existantes. Par contre j'ai du mal à comprendre l'intérêt en dynamique (pas la beauté de la chose, l'intérêt)
C# est un langage destiné à être utilisé, pas destiné à des fins académiques, ce qui explique de nombreux choix de conceptions.
Donne moi le nom d'un seul langage "moderne" qui intègre tout tes killerfeatures et qui soient utilisées parcque utilisable et simple à apréhender ?-
[^]Re: révolutionnaire !
Posté par thecat () le 04/10/2004 à 17:44. (lien). É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é.-
[^]Re: révolutionnaire !
Posté par reno () le 04/10/2004 à 18:12. (lien). Évalué à 2.>>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.
Si le coté des admirateurs de Java "nous on n'a pas l'héritage multiple qui est compliqué mais on a les interfaces, c'est mieux", alors que les interfaces sont un sous-cas de l'héritage multiple m'a toujours fait beaucoup rire, je ne sais pas si l'héritage multiple est indispensable: certains langages tels Ruby, D utilise des "mix-in" a la place de l'héritage multiple.
J'avoue avoir beaucoup de mal a comparer mix-in et héritage multiple, car j'ai du mal a comprendre ce qu'est un "mix-in"..
En tout cas, cela doit être plus simple a implementer dans le compilateur: c'est la justification des concepteurs de D.
-
[^]Re: révolutionnaire !
Posté par TImaniac (page perso, ) le 04/10/2004 à 19:38. (lien). Évalué à 1.En faisant simple, c'est de pouvoir contraindre un parametre générique à n'etre que d'un certains type,
Oué enfin la solution C# ne permet effectivement pas d'imposer un type, mais permet d'imposer une interface... donc bon pour moi l'utilité est la même, il n'y a donc pas de lacune pour ce cas précis.
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.
De plus ta solution n'est pas réalisable quand ce n'est pas toi qui a concu la bibliothèque.
? 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 ne vois vraiment pas le rapport avec la choucroute, ou alors tu t'explique ou alors je comprend mal. QUand à mon hack immonde, désolé mais je le trouve vraiment élégant, implémenter une interface en lecture/écriture sans autoriser tout le monde à y accéder, je trouve ça class.
Laisse les Aspect ou ils sont!
Je te propose une solution, et tu me dis de la laisser tomber. Poutant elle marche très bien. Uen variante consiste à injecter du code à travers des infos passées en méta-données, là encore de manière élégante. Arrête de snober tout ce qui résoud le problème.
Mais sur ce sujet, je suis plutot sceptique sur la reelle pertinance. [multi-langages]
Ben, c'est vrai que recompiler une application existante en .NET grâce au support multi-langages c'est parfaitement inutile, c'est vrai que laisser le choix au programmeurs du langage dans un projet (ok au sein d'un même projet c'est discutable) sans se soucier de comment l'API sera utilisé et par qui, c'est encore plus inutile. D'ailleur c'est rigolo, mais pour tous les langages de la plateforme 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é...
et du coup tu contournera le problème en duplicant ton code
Non pas forcement, il y a toujours une autre solution. Mais je maintient ce que je dis : l'héritage multiple peut poser des problèmes (multiples c'est le cas de le dire), ne serais-ce qu'à cause de l'héritage de concepts à la signature identique et à d'autres sortes de conflits.
Le fait même d'avoir conservé ce mot clef devrait faire condamner ce langage par toutes personnes ayant compris le paradigme objet
Ben désolé il me semble avoir compris le "paradigme" objet, et j'attend une explication. SI tu veux parler du choix d'avoir mis en "final" par défaut, ben l'explication est par ici : www.artima.com/intv/nonvirtual.html .
java lui etait innovant pour l'epoque
je suis tout à fait d'accord. Dommage que ce n'est pas le cas de cette version.
il n'apporte riens, ou plutot apporte n'importe-quoi.
C# a peut-être copier des fonctionnalités d'autres langages sans vraiment rien inventer, mais il a innover comme l'a fait Java à son époque : il a inclu dans un même langages des principes et techinques jusque là dispersées dans différents langages. Java5, dont on parle actuellement, n'apporte rien de plus que C#, toutes les fonctionnalités existant dans un même langage : C#.
Mais bon c'est vrai que avoir inclu dans un mêmes des petits trucs vraiment utiles (par rapport à la covariance qui est un concept facilemetn contournable) c'est vraiment du n'importe-quoi. Et puis c'est vrai que le concept d'événement qui permet d'utiliser le patron de conception Observateur facilement c'est inutile. Et puis c'est vrai que avoir rajouter la possibiliter de checker les débordement dans les opérations élémentaires c'est n'importe quoi. Et puis tout ces petits trucs tirés à droite à gauche qui rende ce langage agréable, comme le foreach, les propriétés, ou encore les métas-datas, les itérateurs, et bien sûr tout ce qui touche le confort pour la réutilisation de code : les pointeurs, la notion de structure, de stack, etc. Mais bon tout celà c'est n'importe quoi. Pourtant dans la pratique c'est super utile, en tout cas beaucoup plus que la covariance ou l'héritage multiple.
Eiffel propose tout cela, et est portable (niveau source) sur beaucoup d'architecture.
Voilà, superbe langage. Mais du point de vu "industriel" comme tu dis : rien que sur un point, facilite-t-il la réutilisation de l'existant ? Ah vi y'a une méthode simple : il cible .NET ;)-
[^]Re: révolutionnaire !
Posté par thecat () le 04/10/2004 à 22:17. (lien). Évalué à 4.>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 TImaniac (page perso, ) le 05/10/2004 à 06:02. (lien). Évalué à 2.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 Philip Marlowe (Jabber id, ) le 05/10/2004 à 07:16. (lien). Évalué à 1.Il y a un mécanisme appelé par le mot-clef external qui permet de réutiliser du code écrit dans un autre langage. J'ai déjà ainsi recyclé du code C en l'encapsulant dans du code Eiffel. Ca fonctionne bien et c'est facile à utiliser. Ca marche aussi pour le C++ et, je crois, le Fortran.
-
[^]Re: révolutionnaire !
Posté par Miguel Moquillon (page perso, ) le 05/10/2004 à 12:46. (lien). Évalué à 1.A t'on vraiment vraiment la même définition de covariance ?
Je me pose la question par rapport au mot-clé 'out' que tu apportes comme solution.
La covariance est la faculté de raffiner le type des paramètres d'une méthode en sous-types.
Par exemple, covariance des paramètres et du résultat de retour :
class Number
add (other: Number): Number
end
class Integer <: Number
add (other: Integer): Integer
end
Bien sûr, avec la généricité, si elle le permet, on peut se permettre une écriture à la F-Bound:
class Number [ T <: Number [T] ]
add(other: T): T
end
class Integer [ T <: Integer [T] ] <: Number [ T <: Number [T] ]
end
Sinon, il apparaitrait que C# 2.0 intégrera la généricité contrainte (si j'ai bien compris). Il apparaitra, si j'ai toujours bien compris avec Visual .NET 2005.
A part ça, je comprends que les développeurs Microsoft s'exaltent face à C#. Jusqu'à présent, ils fallaient qu'ils se tappent Visual C++ ou Visual Basic. Deux langages qui n'ont d'objet que leur prétention (bon, d'accord, j'exagère), un peu comme bcp de développeurs d'ailleurs (ho la la, que je suis méchant, vraiment :) ).
Et tout d'un coup, on leur propose un langage des années 90, né au 21e siècle, C#. Pour eux
-
-
-
-
-
-
-
-
-
-
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.