Moonlight n'est pas distribué directement avec le pack de codecs de Microsoft. En tout cas pas par la page de téléchargement en lien ici. Ces derniers peuvent être téléchargés par l'utilisateur qui le souhaite, et c'est proposé à la première tentative de lecture d'un fichier qui pourrait avoir besoin de ces codecs.
Il est aussi important de noter qu'il est toujours tout à fait possible de compiler son propre plugin en utilisant ffmpeg au lieu des codecs Microsoft.
A voir aussi, un plugin Firefox pour lire les fichiers wmv et wma directement, et qui utilise en fait Moonlight pour lire ces fichiers: http://abock.org/2009/02/11/announcing-moonshine-the-project(...) : Moonshine. Très pratique pour ceux qui n'ont pas réussi comme moi à faire marcher le support de Totem, et qui ont Moonlight d'installé.
C'est vrai que Mono et pnet ne montrent pas du tout que .net soit portable hein.
Mono en fonctionnant sur x86, x86-64, ppc, sparc, ARM et j'en passe, pour des OS comme Linux, Solaris, *BSD, Mac OS X ou Windows, ne montre pas du tout que .net est portable.
Et Microsoft lui même, en sortant un Rotor qui fonctionnait pour sa version 1 sur FreeBSD, Mac OS X, et Windows, montre que .net n'est pas portable.
C'est juste un format de fichier !!!
Il se trouve que Microsoft qui a créer .net, a utilisé son format pour ses exécutables. Ce qui fait donc qu'un fichier .net est un véritable fichier PE32 ou PE32+ (donc 32 ou 64bits, ça importe quand on doit appeler du code natif 32 ou 64 bits).
Et que donc un loader qui comprend les fichiers PE peut comprendre un binaire .net, mais devra faire appel bien sur à une VM pour exécuter le code intermédiaire.
C'est ce que fait le PE loader de WinXP et 2003, qui quand ils reçoivent un binaire, vérifie s'il a son champ spécial dans son header, et dans ce cas là passe la main à .net, et sinon continue son bonhomme de chemin.
Le code X86 inclus dans le binaire n'est exécuté que par les loaders qui ne comprennent pas ce petit champ spécial (ceux de Win2K et 98, youahou). Même Wine gère ce champ, maintenant qu'on peut exécuter des applis .net dans Wine.
En fait le problème je crois, c'est que tu ne comprends pas bien comment tout ça marche.
Et bien là, non, c'est de la tromperie : c'est signé comme un exécutable PE x86-32 pour Windows, mais ce n'en est pas un.
Bien sur que si c'en est un. C'est un exécutable PE32 ou PE32+ tout ce qu'il y a de plus normal, avec une caractéristique particulière, il a un header un champ spécial COM2+ (le pre pre pre nom de .net).
Et tu pourrais très bien le lancer dans Wine en théorie. Dans le cas où le loader ne reconnaît pas directement l'exécutable comme contenant du code .net (comme celui de Win2000), il y a un bout de code natif qui jump vers une librairie native du Framework .net, déclenchant le lancement de la CLR, et l'exécution du code managé.
Donc Wine peut très bien consommer un tel fichier, mais devrait sûrement se plaindre de la non existence de cette librairie particulière.
Donc si on prends ton exemple:
Quand je trouve un exécutable qui est une archive Zip, je regarde un peu plus loin, et si je vois que c'est un JAR, j'essaie de le lancer avec Java.
On peut le transformer en:
Quand je trouve un exécutable qui est un fichier PE, je regarde un peu plus loin, et si je vois que c'est un PE avec un header pour du code managé, j'essaie de le lancer avec Mono.
Non, c'est complètement dépendant de l'implémentation du GC. La plus part du temps, tu ne sais pas quand le GC passe. Mais effectivement, il se charge de nettoyer le tas (et selon son implémentation, de le réorganiser).
Et bien ça dépend de l'implémentation. Si tu travailles en LINQ to Objects, donc en mémoire, le moyen `standard` d'itérer sur un flux d'objets, c'est d'utiliser le même mécanisme qu'un foreach: les énumerateurs.
Par contre, dans le cas où tu implémentes un provider LINQ, que ce soit vers un SGBDR, ou une autre source de données, et bien non, il ne va pas y avoir récupération de toutes les données puis filtre en mémoire.
LINQ va te permettre de récupérer une meta-requête, donc une représentation du code de la requête, qu'on appelle entre nous un expression tree. Et on va donc à partir de cette représentation du code C#, créer une requête correspondante, pour la source de données sous-jacente, donc du SQL, ou autre.
Oui, les IDEs comme le compilateur vont ici faire le même travail, regarder le type de l'expression à droite de l'affectation. Ensuite on peut aimer la rigueur de Java et de C# tout en appréciant un côté moins verbeux.
Moi je connais surtout des outils pour les développeurs. Ceux que j'utilise:
Reflector, NClass, LinqPAD, IronEditor, NUnit.
Reflector par exemple c'est un truc que j'aime bien montrer en démo. C'est utilisé par la grande majorité des développeurs .net. Et c'est aussi simple que de le télécharger, et de faire un mono Reflector.exe.
Je suis assez d'accord avec toi. Après voilà, il y a combien de programmeur C# pour un programmeur Lisp ou Haskell ?
C'est ce que je dis, si ça permet de mettre en avant des concepts intéressants comme ceux-ci, dans un langage mainstream, et peut être d'intéresser certains développeurs vers autre chose, moi je dis tant mieux.
50% des applications .net au monde, ça fait combien d'applications par rapport au nombre d'application sur Linux ? Perso j'en ai aucune idée, mais j'ai une petite idée d'où la balance penche.
Mono est parfois plus rapide que .net, souvent moins rapide, mais j'aimerais bien voir un cas où on est «minable». Et si on en trouve (c'est possible, je dis pas), il suffit de rapporter un bug.
Et pour le reste, c'est surtout un problème du côté des applications. Après oui, Mono n'implémente pas .net 3.0, mais a des briques de .net 3.5. Mais bon, des applis WPF, j'en vois pas encore beaucoup quoi.
Et oui, dans l'ensemble, il faut faire des analyses avec MoMA, pour voir qu'un grand nombre d'applications peuvent être portées avec des changements mineurs (voir la présentation de Miguel au FOSDEM par exemple). Parce que souvent, le problème est dans l'application.
Sans déconner, tu viens d'apprendre qu'on a bien bosser depuis Mono 1.0 (2004). Nous nous sommes énormément servi d'un outil appellé MoMA pour déterminer quelles étaient les APIs les plus utilisées qui empêchaient de porter le gros des applications. Et on les a implémentées.
Donc oui, maintenant, le gros des applications non portables, sont du au fait que les applications utilisent des fonctionnalités natives. Mais ça n'enlève pas qu'il reste du travail pour fixer des bugs et implémenter d'autre chose, et encore augmenter le nombre d'applications portables sans modifications.
C'est surtout que tu ne connais pas .net. L'un des buts avoué de .net, est une très bonne interopérabilité avec l'existant natif. Et ce, en particulier grâce à ce mécanisme de Platform Invoke.
Et donc, beaucoup d'applications .net sont construites sur de l'existant natif, voir même, utilisent directement des fonctions et des primitives spécifiques à leur environnement.
Donc oui, certaines applications ne sont par définition non portable. Ajoute à ça que certains développeurs sont peu regardant sur comment écrire du code cross-platform, et voilà. Mais au final, c'est le même problème avec les applications Java + JNI qui utilisent du code natif non portable.
Et puis ça va dans les deux sens. Une application Mono écrite spécifiquement pour Linux en utilisant certaines fonctionnalités spécifiques à Linux ne sera pas forcément portable vers Windows.
Donc c'est un problème du niveau de l'application, pas de la plateforme, pour la plus part des cas. Après bien sur, il reste des bugs et des librairies non implémentées, mais c'est loin de représenter le gros des applications non portables.
En fait, C# c'est pas totalement différent de C# 2, et il est très facile de faire retrouver ses petits à un programmeur C# 2 en lui expliquant trois choses.
Trois choses c'est pas si énorme.
La première c'est l'inférence de type. Ce n'est qu'un de laisser le compilateur définir le type la variable. Plutôt que de l'écrire soit même. Entre:
Dictionary<string, object> d = new Dictionary<string, object> ();
et
var cache = new Dictionary<string, object> ();
Je sais ce que je préfère. En plus ça force souvent le programmeur à mieux nommer sa variable, pour mieux refléter son but.
La seconde c'est les méthodes d'extensions. Attention, encore une fois, ce n'est que du sucre syntaxique. Ce sont des simples méthodes statiques, que le compilateur peut appeler comme des méthodes d'instance. Les mêmes règles s'appliquent qu'avant.
Mais au lieu d'écrire:
byte [] b = ...;
int c = Utilities.ReadCompressed (b, pos);
On peut écrire:
byte [] b = ...
int c = bytes.ReadCompressed (pos)
Pour peut que l'on ait défini une méthode d'extension.
Voilà, et la dernière chose, c'est que la syntaxe `from where select`, est en fait utilisé par le compilateur comme une suite d'appel à des méthodes d'extensions.
string [] args = ...;
IEnumerable<string> big = from a in args where arg.Length > 10 select arg.ToUpper ();
Allez si, j'ai oublié une chose, la syntaxe des expressions lambdas en C# 3, qu'on peut expliquer à un programmeur C# 2 comme une méthode anonyme, plus simplement déclarée.
Ainsi, dans l'exemple précédent, au lieu d'écrire:
Voilà, c'était le post «Les nouveautés de C# 3 du point de vue pour le programmeur C# 2»
Petite note personnelle, pour avoir passé plus de 6 mois à implémenter LINQ dans Mono, et pour avoir implémenter un provider LINQ, je peux dire que c'est un des composants les mieux pensés du framework .net, où tout s'emboîte vraiment logiquement.
Il ne faut pas se focaliser par l'aspect soudainement non typé, ce n'est surtout pas du Visual Basic ou du JavaScript avec du Late-Binding. Et oui, C# s'oriente petit à petit, vers le fonctionnel. Il faut dire que ce n'est pas donné à tout le monde de programmer avec un langage fonctionnel, et que si ça permet d'ouvrir les masses au fonctionnel, je suis totalement pour le fait que ce soit partiel.
Ça c'est ton avis d'expert. Mais moi qui travaille en C# depuis sa toute première beta jusqu'à maintenant, je peux te dire qu'on peut réaliser en C# 3 des choses plus simplement, de manière plus claire, plus aérées, et plus descriptives.
Et puis tout le monde sait que l'inférence de type la compréhension de liste rendent les programment illisibles, c'est bien connu. En particulier tous les programmeurs qui utilisent des langages fonctionnels tous les jours.
Cela dit c'est comme pour tout, on peut abuser et abuser de telle ou telle spécificités, et mal écrire du code. Oui, on peut encore le faire.
C# est un language à typage fort. Seulement il fait de l'inférence de type pour permettre des déclarations plus concises. On aime ou on aime pas, mais c'est possible. Il reste que dans ce cas, il sera impossible d'assigner à la variable `rss` une expression d'un autre type que XDocument.
Et c'est particulièrement utile dans le cas de requêtes LINQ complexes où on sait juste que la requête LINQ nous renvoit un flux d'objects typés.
Et non, il ne manque pas de point virgule. C# introduit une nouvelle expression `from` qui a de multiples clauses. Pareil, on aime ou on aime pas cette syntaxe, sachant que ce n'est que du sucre syntaxique, et qu'on peut très bien réaliser cette partie en utilisant une peut être plus verbeuse, mais plus classique, chaîne d'appel de méthodes.
Visiblement, c'est déjà corrigé en immaculé. On peut se demander pourquoi il est rangé au placard du coup, l'immaculé tailleur. Parce que, partie comme elle est, elle va bientôt nous sortir une sex-tape.
Mais enfin. J'ai jamais dis qu'on était les meilleurs ou quoi que ce soit. Par contre je pense clairement que .net, et par conséquent, Mono, est une très bonne plate-forme de développement. Certainement pas adapté à tous les usages, mais assez large pour faire pas mal de choses intéressantes.
Ex con : on est sur un truc qui est "le probleme du suivi de ms pour la gestion de la compatibilité avec mono". Ca sert à quoi de dire "non mais ce langage est génial" ?
A te justifier de travailler sur mono ? Tu fais ce que tu veux.
Excès d'enthousiasme pour un truc qui me passionne ? Je n'ai certainement pas à me justifier, j'ai un boulot qui me passionne, tout va bien pour moi, merci.
Qu'on me reproche d'être trop enthousiaste, d'accord. J'avais prévenu, je ne suis pas forcément objectif. Mais si je peux montrer et expliquer mon point de vue, je ne me sens pas le besoin de démontrer par A + B que j'ai raison.
Je ne suis pas un évangéliste, je ne suis pas ici pour vous convertir à Mono.
Mon avis est qu'ils auraient mieux fait d'essayer de faire des librairies java ou autres trucs du même acabit plutot que d'essayer tout le temps de tout réinventer/concurrencer java.
Ça c'est oublié les problèmes juridiques qu'il y a eu entre Microsoft et Sun. Et que Microsoft voulait faire évoluer le langage et la plate-forme, et que ça n'allait pas à Sun.
Un technique c'est pas un gars qui s'arrête aux faits normalement ?
Alors je ne suis pas juste un technique :) Parce que je le veuille ou non je mets beaucoup d'affect dans mon travail. Parce que c'est pas juste un boulot pour moi, ce que je fais.
Mais sentez vous libre de me reléguer au rang des sales fan-boy au côté d'Iznotgood :)
J'ai dis que c'était forcément dérangeant ?
Toi non, enfin je sais plus, mais c'est quand même ce qui est reproché à Mono, que des gens l'utilisent pour créer des applications libres, et que ce ne soit pas juste utilisé comme Wine.
Donc oui, une partie de Mono est «condamnée» à suivre ce que fait Microsoft.
Et c'est ce que reprochais patrick_g, à ce que j'en ai compris.
Oui nan mais je comprends le reproche et la crainte qu'on peut avoir. Mais j'ai le droit de ne pas la trouver fondée.
# Une précision
Posté par Jb Evain (site web personnel) . En réponse à la dépêche Sortie de Moonlight 1.0. Évalué à 3.
Il est aussi important de noter qu'il est toujours tout à fait possible de compiler son propre plugin en utilisant ffmpeg au lieu des codecs Microsoft.
A voir aussi, un plugin Firefox pour lire les fichiers wmv et wma directement, et qui utilise en fait Moonlight pour lire ces fichiers: http://abock.org/2009/02/11/announcing-moonshine-the-project(...) : Moonshine. Très pratique pour ceux qui n'ont pas réussi comme moi à faire marcher le support de Totem, et qui ont Moonlight d'installé.
(Et aussi c'est VB.NET, pas VB# :)
[^] # Re: Portable executable win32
Posté par Jb Evain (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 2.
C'est vrai que Mono et pnet ne montrent pas du tout que .net soit portable hein.
Mono en fonctionnant sur x86, x86-64, ppc, sparc, ARM et j'en passe, pour des OS comme Linux, Solaris, *BSD, Mac OS X ou Windows, ne montre pas du tout que .net est portable.
Et Microsoft lui même, en sortant un Rotor qui fonctionnait pour sa version 1 sur FreeBSD, Mac OS X, et Windows, montre que .net n'est pas portable.
C'est juste un format de fichier !!!
Il se trouve que Microsoft qui a créer .net, a utilisé son format pour ses exécutables. Ce qui fait donc qu'un fichier .net est un véritable fichier PE32 ou PE32+ (donc 32 ou 64bits, ça importe quand on doit appeler du code natif 32 ou 64 bits).
Et que donc un loader qui comprend les fichiers PE peut comprendre un binaire .net, mais devra faire appel bien sur à une VM pour exécuter le code intermédiaire.
C'est ce que fait le PE loader de WinXP et 2003, qui quand ils reçoivent un binaire, vérifie s'il a son champ spécial dans son header, et dans ce cas là passe la main à .net, et sinon continue son bonhomme de chemin.
Le code X86 inclus dans le binaire n'est exécuté que par les loaders qui ne comprennent pas ce petit champ spécial (ceux de Win2K et 98, youahou). Même Wine gère ce champ, maintenant qu'on peut exécuter des applis .net dans Wine.
En fait le problème je crois, c'est que tu ne comprends pas bien comment tout ça marche.
[^] # Re: Portable executable win32
Posté par Jb Evain (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 3.
Bien sur que si c'en est un. C'est un exécutable PE32 ou PE32+ tout ce qu'il y a de plus normal, avec une caractéristique particulière, il a un header un champ spécial COM2+ (le pre pre pre nom de .net).
Et tu pourrais très bien le lancer dans Wine en théorie. Dans le cas où le loader ne reconnaît pas directement l'exécutable comme contenant du code .net (comme celui de Win2000), il y a un bout de code natif qui jump vers une librairie native du Framework .net, déclenchant le lancement de la CLR, et l'exécution du code managé.
Donc Wine peut très bien consommer un tel fichier, mais devrait sûrement se plaindre de la non existence de cette librairie particulière.
Donc si on prends ton exemple:
Quand je trouve un exécutable qui est une archive Zip, je regarde un peu plus loin, et si je vois que c'est un JAR, j'essaie de le lancer avec Java.
On peut le transformer en:
Quand je trouve un exécutable qui est un fichier PE, je regarde un peu plus loin, et si je vois que c'est un PE avec un header pour du code managé, j'essaie de le lancer avec Mono.
Dingue, ça marche.
[^] # Re: C# n'est pas un langage à typage fort !
Posté par Jb Evain (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 2.
[^] # Re: C# n'est pas un langage à typage fort !
Posté par Jb Evain (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 2.
[^] # Re: C# n'est pas un langage à typage fort !
Posté par Jb Evain (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 2.
[^] # Re: C# n'est pas un langage à typage fort !
Posté par Jb Evain (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 5.
Par contre, dans le cas où tu implémentes un provider LINQ, que ce soit vers un SGBDR, ou une autre source de données, et bien non, il ne va pas y avoir récupération de toutes les données puis filtre en mémoire.
LINQ va te permettre de récupérer une meta-requête, donc une représentation du code de la requête, qu'on appelle entre nous un expression tree. Et on va donc à partir de cette représentation du code C#, créer une requête correspondante, pour la source de données sous-jacente, donc du SQL, ou autre.
[^] # Re: C# n'est pas un langage à typage fort !
Posté par Jb Evain (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 2.
IEnumerable<string> persons = GetPersonList (...);
Où GetPersonList renverrait un type concret, genre List<string>.
Encore une fois, l'inférence de type n'a rien de magique, et n'est utile que dans certains cas.
[^] # Re: C# n'est pas un langage à typage fort !
Posté par Jb Evain (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 2.
[^] # Re: C# n'est pas un langage à typage fort !
Posté par Jb Evain (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 2.
Voir les slides 15 à 18 de: http://evain.net/conf/Db4oLinq-dUC08.pdf
Et bien vu pour l'erreur :)
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Jb Evain (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 2.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Jb Evain (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 2.
Bah et pourquoi ça ?
Y a pleins d'applications métiers passées dans MoMA, et qui marchent bien aussi.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Jb Evain (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 2.
Reflector, NClass, LinqPAD, IronEditor, NUnit.
Reflector par exemple c'est un truc que j'aime bien montrer en démo. C'est utilisé par la grande majorité des développeurs .net. Et c'est aussi simple que de le télécharger, et de faire un mono Reflector.exe.
[^] # Re: C# n'est pas un langage à typage fort !
Posté par Jb Evain (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 2.
C'est ce que je dis, si ça permet de mettre en avant des concepts intéressants comme ceux-ci, dans un langage mainstream, et peut être d'intéresser certains développeurs vers autre chose, moi je dis tant mieux.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Jb Evain (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 1.
50% des applications .net au monde, ça fait combien d'applications par rapport au nombre d'application sur Linux ? Perso j'en ai aucune idée, mais j'ai une petite idée d'où la balance penche.
[^] # Re: polymique...
Posté par Jb Evain (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 4.
Et pour le reste, c'est surtout un problème du côté des applications. Après oui, Mono n'implémente pas .net 3.0, mais a des briques de .net 3.5. Mais bon, des applis WPF, j'en vois pas encore beaucoup quoi.
Et oui, dans l'ensemble, il faut faire des analyses avec MoMA, pour voir qu'un grand nombre d'applications peuvent être portées avec des changements mineurs (voir la présentation de Miguel au FOSDEM par exemple). Parce que souvent, le problème est dans l'application.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Jb Evain (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 2.
Donc oui, maintenant, le gros des applications non portables, sont du au fait que les applications utilisent des fonctionnalités natives. Mais ça n'enlève pas qu'il reste du travail pour fixer des bugs et implémenter d'autre chose, et encore augmenter le nombre d'applications portables sans modifications.
[^] # Re: Tire de l'annonce sur slashdot!
Posté par Jb Evain (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 6.
Et donc, beaucoup d'applications .net sont construites sur de l'existant natif, voir même, utilisent directement des fonctions et des primitives spécifiques à leur environnement.
Donc oui, certaines applications ne sont par définition non portable. Ajoute à ça que certains développeurs sont peu regardant sur comment écrire du code cross-platform, et voilà. Mais au final, c'est le même problème avec les applications Java + JNI qui utilisent du code natif non portable.
Et puis ça va dans les deux sens. Une application Mono écrite spécifiquement pour Linux en utilisant certaines fonctionnalités spécifiques à Linux ne sera pas forcément portable vers Windows.
Donc c'est un problème du niveau de l'application, pas de la plateforme, pour la plus part des cas. Après bien sur, il reste des bugs et des librairies non implémentées, mais c'est loin de représenter le gros des applications non portables.
[^] # Re: polymique...
Posté par Jb Evain (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 5.
C'est objectif et argumenté ça tiens.
[^] # Re: F-Sport, Tomboy et Beagle sont 3 applications fort sympathiques
Posté par Jb Evain (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 3.
[^] # Re: C# n'est pas un langage à typage fort !
Posté par Jb Evain (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 6.
Trois choses c'est pas si énorme.
La première c'est l'inférence de type. Ce n'est qu'un de laisser le compilateur définir le type la variable. Plutôt que de l'écrire soit même. Entre:
Dictionary<string, object> d = new Dictionary<string, object> ();
et
var cache = new Dictionary<string, object> ();
Je sais ce que je préfère. En plus ça force souvent le programmeur à mieux nommer sa variable, pour mieux refléter son but.
La seconde c'est les méthodes d'extensions. Attention, encore une fois, ce n'est que du sucre syntaxique. Ce sont des simples méthodes statiques, que le compilateur peut appeler comme des méthodes d'instance. Les mêmes règles s'appliquent qu'avant.
Mais au lieu d'écrire:
byte [] b = ...;
int c = Utilities.ReadCompressed (b, pos);
On peut écrire:
byte [] b = ...
int c = bytes.ReadCompressed (pos)
Pour peut que l'on ait défini une méthode d'extension.
Voilà, et la dernière chose, c'est que la syntaxe `from where select`, est en fait utilisé par le compilateur comme une suite d'appel à des méthodes d'extensions.
Ainsi au lieu d'écrire:
string [] args = ..;
IEnumerable<string> big = args.Where (arg => arg.Length > 10).Select (arg => arg.ToUpper ());
On peut écrire:
string [] args = ...;
IEnumerable<string> big = from a in args where arg.Length > 10 select arg.ToUpper ();
Allez si, j'ai oublié une chose, la syntaxe des expressions lambdas en C# 3, qu'on peut expliquer à un programmeur C# 2 comme une méthode anonyme, plus simplement déclarée.
Ainsi, dans l'exemple précédent, au lieu d'écrire:
args.Where (delegate (string arg) { return arg.Length > 10; })
J'ai écris:
args.Where (arg => arg.Length > 10);
Où on bénéficie de l'inférence de type.
Voilà, c'était le post «Les nouveautés de C# 3 du point de vue pour le programmeur C# 2»
Petite note personnelle, pour avoir passé plus de 6 mois à implémenter LINQ dans Mono, et pour avoir implémenter un provider LINQ, je peux dire que c'est un des composants les mieux pensés du framework .net, où tout s'emboîte vraiment logiquement.
Il ne faut pas se focaliser par l'aspect soudainement non typé, ce n'est surtout pas du Visual Basic ou du JavaScript avec du Late-Binding. Et oui, C# s'oriente petit à petit, vers le fonctionnel. Il faut dire que ce n'est pas donné à tout le monde de programmer avec un langage fonctionnel, et que si ça permet d'ouvrir les masses au fonctionnel, je suis totalement pour le fait que ce soit partiel.
[^] # Re: C# n'est pas un langage à typage fort !
Posté par Jb Evain (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 1.
Et puis tout le monde sait que l'inférence de type la compréhension de liste rendent les programment illisibles, c'est bien connu. En particulier tous les programmeurs qui utilisent des langages fonctionnels tous les jours.
Cela dit c'est comme pour tout, on peut abuser et abuser de telle ou telle spécificités, et mal écrire du code. Oui, on peut encore le faire.
[^] # Re: C# n'est pas un langage à typage fort !
Posté par Jb Evain (site web personnel) . En réponse à la dépêche Mono 2.0 : le singe continue ses grimaces. Évalué à 6.
Et c'est particulièrement utile dans le cas de requêtes LINQ complexes où on sait juste que la requête LINQ nous renvoit un flux d'objects typés.
Et non, il ne manque pas de point virgule. C# introduit une nouvelle expression `from` qui a de multiples clauses. Pareil, on aime ou on aime pas cette syntaxe, sachant que ce n'est que du sucre syntaxique, et qu'on peut très bien réaliser cette partie en utilisant une peut être plus verbeuse, mais plus classique, chaîne d'appel de méthodes.
# Immaculé
Posté par Jb Evain (site web personnel) . En réponse au journal Les bourdes de nos journalistes. Évalué à 4.
[^] # Re: Bon bon bon
Posté par Jb Evain (site web personnel) . En réponse au journal Pourquoi Mono/C# est une folie. Évalué à 4.
Ex con : on est sur un truc qui est "le probleme du suivi de ms pour la gestion de la compatibilité avec mono". Ca sert à quoi de dire "non mais ce langage est génial" ?
A te justifier de travailler sur mono ? Tu fais ce que tu veux.
Excès d'enthousiasme pour un truc qui me passionne ? Je n'ai certainement pas à me justifier, j'ai un boulot qui me passionne, tout va bien pour moi, merci.
Qu'on me reproche d'être trop enthousiaste, d'accord. J'avais prévenu, je ne suis pas forcément objectif. Mais si je peux montrer et expliquer mon point de vue, je ne me sens pas le besoin de démontrer par A + B que j'ai raison.
Je ne suis pas un évangéliste, je ne suis pas ici pour vous convertir à Mono.
Mon avis est qu'ils auraient mieux fait d'essayer de faire des librairies java ou autres trucs du même acabit plutot que d'essayer tout le temps de tout réinventer/concurrencer java.
Ça c'est oublié les problèmes juridiques qu'il y a eu entre Microsoft et Sun. Et que Microsoft voulait faire évoluer le langage et la plate-forme, et que ça n'allait pas à Sun.
Un technique c'est pas un gars qui s'arrête aux faits normalement ?
Alors je ne suis pas juste un technique :) Parce que je le veuille ou non je mets beaucoup d'affect dans mon travail. Parce que c'est pas juste un boulot pour moi, ce que je fais.
Mais sentez vous libre de me reléguer au rang des sales fan-boy au côté d'Iznotgood :)
J'ai dis que c'était forcément dérangeant ?
Toi non, enfin je sais plus, mais c'est quand même ce qui est reproché à Mono, que des gens l'utilisent pour créer des applications libres, et que ce ne soit pas juste utilisé comme Wine.
Donc oui, une partie de Mono est «condamnée» à suivre ce que fait Microsoft.
Et c'est ce que reprochais patrick_g, à ce que j'en ai compris.
Oui nan mais je comprends le reproche et la crainte qu'on peut avoir. Mais j'ai le droit de ne pas la trouver fondée.