TImaniac a écrit 6420 commentaires

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 ;)

Vous essayer de démontrer quoi là ? Que il faut un certain temps pour porter un API ? Que celà prend plus de 2 jours ? Clap clap clap.
Pour ce qui est du langage en soit, Mono va aussi vite que MS, ayant tous les 2 les spécifs en même temps. Là Sun est seul à sortir une implémentation du langage Java version "5" : c'est pas la même réactivité, pourtant dans le consortium JCP il y a des acteurs "professionnels" comme IBM... Mais bon faut dire que les spécifications définitives de Java 5 ont vraisemblablement permis à tous de partir en même temps : http://www.jcp.org/en/jsr/detail?id=924(...) ...

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 ?

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...

sauf que Delphi cible maintenant .NET dans sa dernière version.
Ça ferais une plus juste comparaison à mon avis.
Pas du tout, celà fait parti d'un des atouts majeurs de la plateforme .NET : elle a été pensé multi-langages, afin notamment de pouvoir programmer dans celui qu'on veut (même si certains sont plus adaptés), mais aussi pour pouvoir réutiliser facilement l'existant. Pareil pour la faciliter d'utiliser des APIs natifs : réutiliser l'existant. A l'opposé Java n'encourage pas à réutiliser l'existant lorsqu'il est natif et ne cherche pas faciliter l'intégration d'autres langages sur sa plateforme.

mais vas pas dire qu'en Java on réinvente à chaque fois la roue
J'ai pas dis à chaque fois. Me faites pas dire ce que je n'ai pas dis ;)

une API qui est pour l'instant plus grande que celle de la plateforme.net
Je suis d'accord, celà est due en partie à la vieillesse de la plateforme Java et justement au fait qu'il faille parfois "réinventer" la roue en Java. DirectX, même si ce n'est pas une priorité, c'était juste un exemple d'API difficilement exploitable en Java, pourtant on peut imaginer qu'une équipe de développement puisse avoir recour à cette techno, propriétaire mais performante. Quand on développe en Java, on s'arrange pour faire avec ce qui est dispo sur cette plateforme, comme tu le soulignes, il y a beaucoup d'API qui ont été portés, cetains étant de simple wrapper JNI (auquel cas c'est comme en .NET, mais en beaucoup moins élégant et pratique) et on ne réinvente pas la roue, mais dans d'autres cas il faut tout recoder.
Je vais prendre l'exemple tout bête du "port" de Quake2 sur la plateforme Java (l'exemple vaut ce qu'il vaut, il faut regarder le point de vue technique) : ils se sont fait chier à refaire un moteur complet (bref réinventer la roue), car impossible d'utiliser l'existant : bref plusieurs mois de boulot par plusieurs programmeurs.
Un autre s'est lancé dans le portage sur .NET : hop il a passé une journée à passer le code original du moteur en C en C++ managed (histoire que ca compile en .NET) et une autre journée de tuning : zou il obtient exactement la même chose, avec une seule commande il compile soit en natif soit en managé, et il obtient les mêmes perfs que l'équipe Java.
Tu vois où je veux en venir ?
Je ne dis pas que c'est toujours le cas (tu ne réinvente pas toujorus la roue !), mais forcer de reconnaître que Java n'aide pas à réutiliser l'existant et a conduit à faire de nombreux API en Java qui existait déjà en natif : beaucoup de perte de temps, avec un avantage : la portabilité.
Moi je préfère faire de la portabilité le jour où j'en ai besoin, plutôt que de m'enmerder avec dès le début parcque je n'ai pas le choix.

Un autre exemple : Mono a vu très rapidement le jour, pourquoi ?
Parcque en très peu de temps on a pu obtenir une plateforme utilisable qui se basait sur un existant fiable : GTK, Mozilla, libxml, Qt, etc. Pas toujours très portable, bien qu'ils aient tout de même choisi leurs technos, ils ont eu rapidement quelque chose d'impressionnant et de relativement stable, en proposant à l'utilisateur des API qu'il connait. En Java je rigole encore du temps qu'il a fallut pour obtenir Swing, sans parler que cette solution est loin d'être parfaite, et question intégration, elle se contente d'essayer d'imiter l'aspect graphique de l'environnement qui l'entour... Clap clap clap. Tout celà parcqu'ils ont voulu réinventer la roue et refaire une couche graphique portable. Résultat : un truc portable, mais un qualité perdue : l'intégration.

.net te dit en fait : hey prenez la facilité !
je dirais plutôt : avec .NET faites simple et utilisez l'existant, soit à travers la simplicité d'utilisation d'API natif, soit à travers le support de nombreux langages permettant de réutiliser du code existant.

tu comprends rien à ce que je dis : je dis juste que la portabilité à un coût, ce n'est pas une chose qui s'acquiert pif paf poum comme ça. Par fois il est plus facile de s'appuyer sur un existant, parfois non portable, quand le besoin de portabilité ne se fait pas sentir. Et il y a pleins de cas où il ne se fait pas sentir : il est de toute façon toujours possibler plus tard de résoudre ce problème en faisant ce travail supplémentaire, mais l'avantage c'est qu'on est pas obligé de le faire directement.

La situation pour Mono est même moins avantageuse que pour Java car .net facilite l'utilisation de bibliothèques natives depuis du code alors que pour Java c'est très fortement déconseillé.
C'est effectivement une des grosses différences philosophiques entre .NET et Java. Java propose de réinventer la roue pour qu'elle soit portable, alors que .NET propose de ne pas perdre du temps et réutiliser l'existant.

Mais c'est un faux débat de dire que Mono a plus de difficulté que une implémentation de l'environnement Java : Mono doit effectivement porter des API natifs, soit en les écrivant, soit en utilisant d'autres API d'une autre plateforme. Mais pour Java on a le même problème : il faut réinventer la roue et recoder. Même inconvénients. Sauf que la solution .NET laisse plus de liberté, notamment lorsque le multi-plateforme n'est pas une priorité.

Tu vois dès que .NET est sorti, il était possible d'utiliser DirectX. Au même titre que OpenGL ou autre. En Java celà a mis combien de temps ? Tout celà parcque Sun préfère la portabilité à la réutilisation. C'est dommage car .NET propose un meilleur compromis : tu veux réutiliser du code sans perdre de temps ? C'est facile, on vous propose tous les outils adéquates dans le langages, et on vous y encourage. Vous voulez porter votre application ? Faites comme en Java, et réinventer la roue, on vous y encorage également.

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 ?

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.

Tu devrais lire les différents documents présentant le JCP sur le site officiel.
Justement, c'est ce que j'ai fait : pourtant ce que je dis est parfaitement vrai :
"Participation as a Member requires you or your organization to sign the Java Specification Participation Agreement (JSPA). The JSPA is a one-year, renewable agreement between you and Sun Microsystems, Inc."
Même si Sun ne contrôle pas les décisions à l'intérieur de l'organisation, c'est Sun qui décide au cas par cas qui a le droit de rentrer ou non. Mais bon, ton commentaire semble plus pertinent, et pourtant tu ne démontres en rien mon affirmation. (elle ne me contredis pas, tes propos étant également exacts)

On se retrouve monsieur Traumat, j'ai justement pris le soin de vérifier mes dires cette fois-ci, t'ayant aperçu dans les parages ;)

meme toi, tu peux participer :)
A condition que Sun veule bien. même si Sun n'est pas seul à décider, Sun "choisi" son entourage, l'indépendance du JCP est toute relative.

Pour les exceptions non checkées, tu peux lire l'avis du concepteur de C# sur le sujet : http://www.artima.com/intv/handcuffs.html(...) . On aime ou on aime pas, mais ses choix sont justifiés, et il faut reconnaître que celà pose pas mal de problème en Java les exceptions, même si le principe est louable.

Ce que je trouve vraiment dommage avec ce Java5, c'est qu'ils se sont contenter d'ajouter des fonctionnalités de C#, sans les reprendre toutes (poutant il y en a encore des intéressantes, peut être pour Java7 ?), et surtout sans rien ajouter d'innovant. Le pire, c'est qu'ils ont préférer sortir directement les generics dans une implémentation plus que contestable, hors ce genre de choix ne se fait pas à la légère, puisque difficile modifiable... ( http://www.artima.com/intv/generics.html(...) ) Franchement je trouve celà dommage, j'aurai largement préférer une saine émulation entre les 2 concurrents.

Enfin longue vie tout de même à cette plateforme, qui a comme gros avantage une certaine maturité et une communauté très active, autour de projets fédérateurs comme Eclipse.

En même temps si tu ne veux pas que ton oeuvre soit diffusé, suffit de ne pas la leur envoyer...

Oui oui il faut que tu racontes à ta carte mère qu'elle serait gentille d'essayer de booter sur ta clé USB :) (c'est pas possible avec toutes les CM cependant, surtout les anciennes)
Tu devrais trouver les fichiers qu'il te faut par ici :
http://download.fedora.redhat.com/pub/fedora/linux/core/test/2.91/i(...)

Sinon après celà marche comme une disquette de boot.

De la même manière que beaucoup préfère acheter leur PC chez le taïwanais du coin. C'est pas nouveau, et à mon avis beaucoup plus significatif que ceux qui achète un PC sous Linux dans ce but d'installer un Windows pirate.

Toujours le même problème : le noyau 2.6 ne rentre plus sur une disquette, voilà pourquoi il n'ya plus d'image de boot proposé pour disquette. Par contre tu en touveras certainement une un peu plus gros, que tu peux mettre sur une clé usb et booter dessus par exemple.

Tu peux aussi te contenter de graver le premier CD et de choisir une installation à partir du disque dur, le premier CD faisant office d'image de boot.

Franchement, peut être que celà vient de mon niveau intellectuel pas assez élevé, mais la question :
"Veuillez indiquer s’il vous plaît dans quelle mesure vous désirez faire ce que les groupes ci-dessous pensent que vous devriez réaliser."
demande trop de relecture.

Ben ma curiosité m'a amener à me demander quelle allait être leur réaction, donc je me suis logiquement mis à leur place.

Le brevet était passé en 96, là il a été annulé.

Oué enfin je voulais parler du point de vue de MS.

Bah y'a pas grand chose de compliqué à comprendre : l'office américain des brevets a invalidé le brevet : résultat il n'est plus nécessaire de se procurer une licence auprès de Microsoft pour utiliser le système de fichier FAT.
Ce qui est bizzare, c'est que Microsoft s'était vu imposer le fait de fournir les spécifs de son format et d'en autoriser l'utilisation et en contre-partie il était laissé le soin à Microsoft de faire payer quelques royalties pour chaque licence... Maintenant on leur leur sucre leur brevet (enfin bon c'est pas une perte, j'aime pas les brevets logiciels), et ils n'ont plus de contrôle sur leur technologie, je suis curieux de savoir comment ils vont réagir :)

Et puis XUL est de loin la technologie la plus avancé aujourd'hui dans le domaine des "clients lourds".
Autant le reste de ton commentaire est tout à fait pertinent, mais alors autant là j'applaudis, c'est vraiment une evidence qui s'impose, que tu démontres ici avec brio.

WinFS demandera touours NTFS en dessous, WinFS est une couche d'abstraction de plus haut niveau, il faut toujours un système de fichier.