Codingly

Arguments nommés et arguments par défaut en C#4

Posted in Posts by Romain Verdier on avril 18, 2010

Guest post de Jb Evain.

J’ai un nouveau pet-peeve [1]. Mais comme pour beaucoup d’entre eux, c’est parce que je me suis longtemps fait avoir. Now that I saw the light, et que je ne me trompe guère plus, voir les autres se tromper m’est tout bonnement insupportable. D’ailleurs mon introduction est amusante, car beaucoup de français ont pour «pet-peeve» l’over utilisation des mots anglais dans une phrase française. Moi qui passe ma journée à lire et à écrire de l’anglais, ça ne me choque plus, vous savez.
(more…)

Publicités
Tagged with: , ,

Convertir implicitement des delegates ayant la même signature

Posted in Articles by Romain Verdier on février 10, 2010

Hier soir, je tombe sur un tweet de Krzysztof Koźmic :

Do I care if it’s Predicate<int> or Func<int>? No, than why won’t C# compiler just live me alone and pick whatever it needs? I DONT CARE

Et là je me dis HAHA LOL MAIS N’IMPORTE QUOI Predicate<int> et Func<int> c’est très différent voilà une bonne occasion pour moi qui ne suis rien de reprendre gratuitement un des contributeurs principaux de Castle sur une étourderie. Et je lui fais remarquer, en gros :

(more…)

Tagged with: ,

Switch sur un type en C#

Posted in Posts by Romain Verdier on octobre 19, 2009

Si vous avez besoin de faire un switch sur un type en C#, la première chose qu’il vous faut faire est de vous demander si vous avez besoin de faire un switch sur un type. Ensuite, demandez-vous si vous avez vraiment besoin de faire un switch sur un type, et forcez-vous à imaginer une solution tirant partie du polymorphisme (c’est presque toujours possible). Si pour une raison quelconque (imaginons-la tout de même légitime), vous ne pouvez pas faire autrement, alors voici ce qu’il faut éviter de faire :
(more…)

Tagged with: ,

Tout ce que vous n’avez pas besoin de savoir au sujet du mot clé event

Posted in Articles by Romain Verdier on août 17, 2009

Vous ne vous êtes jamais demandé à quoi servait, en C#, le mot clé event ? Moi oui. Et je vais même jusqu’à poser la question d’une certaine façon aux gens qui m’entourent, sauf peut-être dans la ligne 2 du métro :

—  A quoi ça sert, le mot clé event ?
—  Bah, à déclarer des events.
—  Oui, mais ça marche pas sans le mot clé event ? En écrivant juste, par exemple :
  public EventHandler Click;
—  Heu, si, je crois.
—  Donc, à quoi ça sert, le mot clé event ?
—  T’es relou, dégage.

Notez qu’à l’oral, il n’y a pas la coloration syntaxique. Je suppose que c’est ce qui conduit assez régulièrement mes interlocuteurs à être désagréables. (J’aime pas les gens désagréables !)

(more…)

Tagged with: ,

Petit rappel sur le Disposing Pattern en C#

Posted in Posts by Romain Verdier on avril 1, 2009

Ca fait longtemps que je veux faire ce post, au sujet d’une question trop souvent négligée : le disposing pattern. On peut voir ça comme un petit rappel, ou un post à classer dans la catégorie « back to basics ». En deux mots, il s’agit de gérer correctement la libération des ressources non-managées, dans un programme managé.

EDIT : Ce post est un poisson d’avril, évidemment. Il vaudrait mieux ne pas utiliser l’implémentation du disposing pattern proposée…

(more…)

Tagged with: , ,

Si les types étaient des animaux, TypedReference serait un ornithorynque

Posted in Articles by Romain Verdier on janvier 15, 2009

Devinette : C’est un type valeur, mais on ne peut pas le caster en object. Il est impossible d’en déclarer des tableaux. On ne peut l’utiliser que pour typer les paramètres de méthodes et les variables locales. Il existe 4 mots clés non documentés en C# qui lui sont directement reliés, et autant d’opcodes en CIL. Il permet notamment le support des varargs, et exactement 8 personnes dans le monde se sont souciées plus de 5 min de son existence.

Je veux parler, bien évidemment, de TypedReference. Je vous propose de découvrir ce type à partir d’un exemple rigolo.
(more…)

Tagged with: , , ,

Cecil.Decompiler : Un décompilateur .NET OpenSource

Posted in Posts by Romain Verdier on décembre 16, 2008

Jean-Baptiste Evain vient de l’annoncer sur son blog : il travaille actuellement sur un nouveau projet particulièrement ambitieux appelé Cecil.Decompiler. Comme son nom l’indique, il s’agit d’un décompilateur .NET basé sur Mono.Cecil (du même auteur) qui permettait déjà de manipuler le langage intermédiaire du CLR.

Quelques jours avant l’annonce officielle, Jb a organisé un Code Camp en Ardèche (près de Lyon) en invitant quelques personnes à travailler avec lui sur ce decompiler. L’idée était avant tout de passer un bon moment, de faire avancer découvrir le projet, mais aussi d’intéresser et d’encourager d’éventuels futurs contributeurs à rejoindre l’initiative.

Comme j’ai eu la chance de faire partie des petits privilégiés, je vais essayer de vous livrer mes impressions à chaud.
(more…)

Le futur de C# ?

Posted in Posts by Romain Verdier on novembre 15, 2008

Le problème de la PDC, quand on y est pas et qu’on est curieux, c’est qu’il faut attendre les vidéos des sessions pour savoir ce qui s’est vraiment passé. Symptôme de naïveté : croire qu’on pourra s’en sortir grâce à la blogosphère. Sérieusement, et je reste sur l’exemple spécifique de C# 4.0, 80% des billets qui sont sortis jusqu’à présent à ce sujet ont simplement contribué à rendre l’écho plus pénible. Un peu partout on peut tomber sur des réactions constructives du genre :

The dynamic keyword is going be abused so much… C# is on its way to becoming PHP.

(more…)

Tagged with: ,

Introduction à Mono.Cecil : Implémenter INotifyPropertyChanged

Posted in Articles by Romain Verdier on novembre 10, 2008

Vous allez probablement m’en vouloir à force, mais j’ai décidé de continuer mes expériences autour d’INotifyPropertyChanged. Cette fois-ci, en utilisant Mono.Cecil pour faire un peu d’IL rewriting. Où comment tisser un aspect sans utiliser de framework AOP. Comparée à celle basée sur PostSharp.Laos, cette solution a un inconvénient majeur : elle est plus roots.

En revanche, aucune autre méthode à ma connaissance ne permet d’obtenir un tissage aussi fin. Par fin, j’entends spécifique, propre, non pollué par le code que génèrent les outils d’AOP classiques pour supporter les mécanismes d’interception. Donc les performances seront à la clé puisqu’une fois l’assembly retravaillé avec Cecil, il ne sera plus possible de faire la différence entre son code IL et celui qui aurait été généré si nous avions implémenté INotifyPropertyChanged à la main. Le développement aura juste été un peu plus cher…

(more…)

Tagged with: , , , ,

Utiliser l’AOP avec PostSharp pour implémenter INotifyPropertyChanged

Posted in Articles by Romain Verdier on octobre 29, 2008

J’ai ce billet dans mes drafts depuis un moment, et il serait peut-être bon de l’en sortir avant qu’il ne soit trop tard… Dans un post récent, je parlais de l’interface INotifyPropertyChanged, en donnant un exemple d’implémentation basée sur les lambda expressions et les expression trees qui permettait d’obtenir une solution fortement typée.

L’AOP peut également être une solution, et peut-être même le meilleur compromis pour peu que l’on en tire partie correctement. Suite à un commentaire de Jb, j’ai essayé de voir ce que pouvait donner l’utilisation d’un tisseur statique comme PostSharp dans ce cas précis.
(more…)

Tagged with: , , , ,