TImaniac a écrit 6423 commentaires

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.

tiens ça me fait penser que je viens de lire celà : http://www.presence-pc.com/news/ISA-le-firewall-de-Microsoft-n5268.(...)

(je ne cherche pas à troller, c'est juste rigolo comme hasard :) )

on va également pouvoir dire "Java ça pue c'est breveté"

C'est pas Java qui est breveté, par contre Java utilise des "concepts" breveté par Kodak.

Enfin ce n'est pas une grande nouvelle en soit, Java viole sûrement pleins d'autres brevets, comme la plupart des solutions informatiques. Ce qui est plus génant par contre c'est que certaines entreprises font valloir "leurs droits", et gagnent des procès concernant des brevets logiciels : ceci est d'autant plus discutable que Kodak estime que sa "propriété intellectuelle" est plagiée, comme sil ils avaient fait un effort sur-humain pour pondre leur "invention" : ils se sont contenter de racheter ces droits à une autre boîte. Comme quoi même un tribunal préfère juger sur la forme plutôt que sur le fond, ce qui rend les brevets logiciels encore plus dangereux.

Ce sont les plus riches qui gagneront : cad ceux qui pourront acheter le maximum de brevets. D'un autre côté je suis content que ce procès est abouti, il a le mérite de lancer une polémique (une de plus me dira-t-on) mais au moins il permet de montrer que les brevets logiciels ne sont pas sans danger sur l'innovation.

?
C'est ce que je reproche à Java : il faut souvent tout réécrire pour tout réutiliser.

Ne fais pas exprês de ne pas comprendre.
Euh, toi tu me dis qu'il manque la plupart des trucs.
Pourtant si tu regardes le volume d'API supportés, ben en gros il manque que System.Windows.Forms, et encore, il est implémenté en partie. Alors dire qu'ils sont loin d'arriver au bout voilà quoi...

Je te trouve un peu naif sur ce coup la :-)
C'est juste que je trouves vraiment petit d'accuser MS de mal documenter ses APIs, alors que dans l'ensemble je trouve ceux de .NET largement plus documentés que ceux de Java.

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# ?

Ils sont masos ces mecs !!!
Comme je vais encore me répéter : là je parles de réutiliser l'existant !!! Je ne vois absolument pas ce qu'il y a de maso de proposer un framework qui permet de réutiliser facilement l'exsistant sans le recoder sur la plateforme, soit en le recompilant si le langage est supporté, soit à travers les possibilités d'appels natifs.

Déconseillé, mais possible. (c'est trés différent)
Et alors ? J'ai dis le contraire peut être ? Effectivement CNI est mieux pour celà, mais il oblige à utiliser gcj non ? Ce n'est pas un peu très limitatif ?
Chez Microsoft ils ont préférer appeler un chat un chat et mettre les pointeurs dans C# quand c'est nécessaire, sans passer par un truc intermédiaire qui cache la réalité mais pas du tout leurs conséquences.

Comme précédemment, je parle toujours et encore de réutilisation de l'existant. Je penses que là tu comprends mieux mes arguments...

+ qq autre. C.a.d trés peu.
Ben voyons. J'ai comme l'impression que tu n'as absolument aucune idée de l'étendue du framework .NET, pourtant c'est un peu de la même ordre de taille que le J2EE... Enfin bref, ASP.NET est 100% compatible par exemple, permet de migrer facilement des applications, tu en fais quoi ?

C'est justement pour ça que j'ai pas trop confiance en M$...
si c'est juste parcqu'ils ont oublier de documenter 2 ou 3 fonctions dans des vieux APIs, voilà quoi...

Moi je fonde mon raisonnement sur la réutilisation du réexistant, et toi t'essai de me contredire en partant d'un nouveau projet... Celà a au moins le mérite de se compléter à défaut de s'opposer :)

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.

Vi sauf que quand tu sort une nouvelle version d'une bibliothèque, tu ne peux pas forcer toutes les applications basées dessus à se recompiler...

Non avec .NET tu es obligé de respecter seulement la CLI. La CLI a été définie pour faciliter la réutilisation d'API en spécifiant certains concepts et méthodes permettant d'assurer l'interopérabilité, mais reste assez limitée pour ne pas contraindre trop l'implémentation de nouveaux langages. Evidemment il reste des contraintes : il faut que le langage soit procédural (ou tout de moins ce qu'il expose) et objet c'est pas plus mal (s'il veut réutiliser). Mais les règles sont bien définies, c'est tout l'intérêt d'un protocole : suffisament précis pour faciliter les communications et suffisament général pour ne pas trop contraindre leur utilisation.

Pur être plus précis, le compilateur Java ne génère qu'une seule représentation du code de la classe générique.

Comment il fait ? Ben, il ajoute des opérations de castings partout, exactement comme tu l'aurais fait, et il met le type "object" partout dans le code de ta classe. Où est l'intérêt ? Si si il y en a un, le compilateur peut otut de même faire une vérification statique de type, alors que si tu l'avais fait toi même, tu aurais du vérifier à la patte tous tes casts. Dans tous les cas, à l'exécution, tous les types primitifs se font boxés et déboxés car transformés en "object", et bien sûr par introspection tu es incapable de savoir que ta classe est une classe générique et tu ne peux bien entendu pas en tirer partie. Autre avantage : il n'ont pas eu besoin d'ajouter d'instruction dans la JVM.

En C#, le compilateur génère une classe qui contient le code, mais avec des attributs indiquant que c'est une classe générique. Déjà lors de l'exécution, tu peux savoir que c'est une classe générique. Lorsque tu demandes une instance de ta classe générique, le compilateur génère une nouvelle version (sauf bien entendu si tu as déjà demandé cette classe avec le même type en paramètre) en y "collant" ton nouveau type : il n'y a aucun cast, les types primitifs ne sont pas boxé (question perfs c'est pas plus mal, surtout quand on sait que les classes génériques sont souvent utiliser pour gérer des collections), et tu n'as rien perdu des possibilités d'introspection.

Sauf que ton compilateur peut très bien faire les appels de méthodes comme il le sens avec les instructions qui lui plait, implémenter un type de base avec une taille de données qui l'amuse, sans parler de sa définition de classe qui ne sera peut-être pas la même, etc. Bref, tu pourras effectivement réutiliser du bytecode, mais le programmeur va devoir faire en sorte que son compilateur respecter toutes les règles de Java, à défaut d'un sous-ensemble plus "friendly" et bien défini. Rien ne vaut des conventions écrites, et un bytecode conçu avec cet objectif (histoire de ne pas non plus limiter les possibilités et/ou les perfs)

et bien sûr, comme tout ce qui tourne avec les classpath, www.ikvm.net (entre autre Eclipse)

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.

Pourquoi tu ramènes cela à .net?
Ben tout simplement parcque la personne à laquelle j'ai répondu répondait elle-même à la possibilité de choisir son langage avec Mono/.NET. Cette personne a voulu montrer que en Java aussi c'était possible, j'ai juste voulu expliquer la différence. Je suis effectivement enthousiaste comme tu l'as remarqué, mais depuis le début, si tu relis tous mes posts, c'est jamais moi qui est commencé à parler de .NET. Je l'ai juste ramené quand le sujet était là, et là c'est le cas ;)

Tout à fait. Alors quand un langage supporte une nouvelle plateforme comme .NET, même s'il y a 2 ou 3 différences, c'est quand même beaucoup plus appréciable comme transition. Je pense notamment au C++ managed qui permet de combiner code natif et code managé, y'a rien de spécial à faire et ça marche : après ils peuvent commencer à utiliser les nouveaux API, écrire le nouveaux code avec, et intégrer facilement l'existant. Pareil pour J# qui propose d'importer un projet Java, avec il est vrai une limitation quand au framework supporté (Java 1.3 seulement pour le moment)

Je n'attaque pas spécialement J2EE là dessus, je dis juste que c'est le choix philosophique de la plateforme Java : limiter les possibilités de réutilisation de code existant (pour moi JNI est ce qu'on peut appeler l'opération de dernière chance, ou alors quand il n'y a pas vraiment le choix comme par exemple OpenGL qui peut difficilement être codé en plus haut niveau sans avoir accès aux drivers). C'est pas du tout la même philosophie que .NET, celà a des inconvénients, que j'ai cité, mais ausis des avantages : ils forcent le portage sur la plateforme en réécrivant le code à réutiliser et on y gagne en portabilité.
Ce que je veux dire, c'est que .NET est moins limitant, C# offre tous les outils adéquate, libre aux développeurs de faire leur choix stratégique, dans tous les cas ça se fera avec pas mal de confort.

Merci pour cet historique de Eiffel, je ne le connaissais pas.

Si tu veux vraiment faire de la méta programmation, je te recommande fortemement Smalltalk-80 ou Squeak
Je veux pouvoir en faire quand j'en ai besoin. Tu me conseille Smalltalk, c'est d'ailleur entre autre de ce langage que s'est inspiré C#. Je préfère utiliser un langage qui est un bon compromis entre fonctionnalités, performances et confort plutôt qu'un langage "joli" mais parfois dur à apréhender. Pour moi le langage doit être là pour me permettre d'exprimer des concepts avec le maximum de confort, sans avoir à trop réfléchir. Ce pourquoi par exemple je n'utilise jamais l'héritage multiple, sachant pertinament que celà va m'obliger à me poser pleins de question quand à aux conséquences. C'est de ce principe qu'est parti le concepteur de C#, c'est pourquoi il n'y a pas d'exceptions rattrapées, c'est pourquoi il n'y a pas d'héritage multiple, c'est pourquoi les méthodes sont finales "par défaut".

Tu peux voir si tu veux le C# comme une opération marketing. Il est évident que ce langage a été développé pour concurrencer Java. Mais ce que j'ai trouvé positif, c'est qu'ils ont vraiment ajouter des petits "+" qui ont su faire la différence en terme de confort et aussi de productivité (réutilisation aisée de code), bref ils ont voulu apporter des nouveautés par rapport au concurrent : c'est d'ailleur pourquoi il a eu beaucoup de succès, et c'est pas pour rien que Java reprend la plupart des petits "+" qui font la différence. C# répond à de vrais besoins, pas à des jolies théories objets.

Après on peut argumenter pendant des heures sur le fait que C# ne suit pas correctement le dernier paradigme objet à la mode avec toutes les fonctionnalités qui font la beauté d'un vrai langage objet, mais ce n'est absolument pas le but de ce langage : il existe pour répondre à des attentes, et les nouveautés apportées apporte un véritable "+" pour la plupart des utilisateurs, et pas seulement les experts. D'ailleur tu sembles clairement indiquer que Java n'était pas pour toi suffisament utilisable par rapport à d'autres langages comme Eiffel. Pourtant pour beaucoup de développeurs, l'histoire a montré que leur point de vue n'était pas du tout le même, et qu'ils n'avaient pas du tout la même notion d'un langage utilisable.

C# et Java ce sont des langages pour la "masse" de développeurs, des langages tout public si on veut, pour la plupart des programmeurs. Je ne vais pas comparer à Eiffel que je ne connais absolument pas, mais à d'autres langages comme OCaml par exemple, qui sont certes très joli et procure une certaine satisfaction lorsqu'on n'a réussi à appliquer à la perfection un concept du langage, mais qui par contre sont destinés à des programmeurs qui aime bien se "branler" le cerveau (excuse moi pour l'expression, mais je trouvais qu'elle correspondait bien ;) )

Sinon, il apparaitrait que C# 2.0 intégrera la généricité contrainte
N'emploi pas le futur, la norme C# 2.0 est sorti il y a maintenant plus d'un an.
Le compilateur de MS est passé depuis un moment en version 2.0. Effectivement elle n'est distribué que dans les version "bétas" de Visual Studio 2005 parcque MS aime bien filer la plateforme complète de développement qui va avec. Mais si tu veux tu peux chopper cette version sans Visual Studio, et Mono a une preview de C# 2.0 depuis un moment, et à un ou 2 détails près c'est parfaitement utilisable (il manque surtout de l'optimisation, mais ça compile et ca fonctionne comme on le souhaite).
Si ca peut te faire plaisir C# est un langage des années 90 (c'est pas entierment faux, ils ont commencé à bosser dessus au 20ème siècle ;)), mais largement plus utile, notamment en ce qui concerne le confort de réutilisation que l'apport de langage du 21ème siècle comme Eiffel, qui sont par contre très joli à montrer à l'université, parcque ils respectent le paradigme objet et tout et tout. Mais désolé, je trouverai toujours plus utile la gestion transparente des évenements et les métas-données que la covariance, même si c'est des fonctionnalités moins récentes et déjà existantes. C# a été conçu comme un best-of des langages industriels, et de ce fait est un langage industriel. J'entend par industriel puissant, agréable et utile, pas seulement sur le papier, mais aussi avec une équipe de programmeurs.

Pour ton vécu et les mecs qui sotn passés de VB à C#, tu aurais pu leur montrer VB.NET, ils auraient eu quasiment les mêmes possibilités qu'en C# en gardant leur syntaxe favorite ;) La transition aurait été plus douce et vous y auriez gagner en productivité ;)

A la grosse différence près que là il n'y a aucun protocole qui défini comment doivent intéragir les langages entre eux, quel format doivent avoir les données. C'est tout l'intérêt de .NET : il y a la CLI qui est clairement définie (Common Language Interface) avec un autre acronyme pour spécifier le format des données à échanger. La plateforme Java n'a pas du tout été conçue avec cet objectif, et même s'il est possible d'implémenter pleins de langages au dessus de la plateforme Java, on est loin de l'interopérabilité qu'offre la plateforme .NET.

La verbosité est un handicap quand elle n'apporte aucune sémantique. C'est le cas quand la plupart des développeurs l'utilise n'importe comment, en méettant par exemple throws Exception devant toutes les méthodes, ou en catchant systématiquement.
Les concepteurs de C# se sont basé la plupart du temps sur des constats fait auprès d'utilisateurs/ddéveloppeurs, notamment Java. Pas seulement sur de jolis principes théoriques, qui dans ce cas précis n'est pas spécialement joli car empêche par exemple de déclencher de nouvelles exceptions à travers une interface, où laisse carrement des "trous" en cas de changement de version d'une classe sans recompilation de la classe utilisatrice.

Maintenant, comme dans Mono, rien n'empêche une appli Java d'appeler des fonctions natives,
Comme je l'ai déjà dis, c'est possible comme dans Mono, mais dans un cas c'est encouragé (avec toutes les facilités qu'offre C# pour, cad la notion de structure, de pointeur, de stack, etc.) et dans l'autre cas c'est déconseillé, avec un JNI inbittable. Heuresement qu'il y a des alternative, mais ce n'est pas du tout la même philosophie entre les 2 plateformes.