Codingly

ALT.NET en France : Présentation AOP, c’est fait.

Romain Verdier — Thu, 18 Jun 2009 08:09:28 +0000

Je me demande si 91 slides valent 1000 mots. Vous pourrez essayer de vous faire une idée puisqu’elles sont disponibles ci-dessous. Je vous conseille de carrément télécharger la présentation si vous êtes intéressés par les animations, puisque certaines (lire : toutes) sont très logiquement tuées par SlideShare.

Bon, pour ma part j’ai trouvé que ça s’était plutôt bien passé considérant que je ne suis pas un speaker – au mieux un sale programmeur – même si j’imaginais une présentation un peu plus courte. J’ai parlé pendant 45 min, je crois, puis j’ai ouvert VS pour la “démo interactive” qui s’est un peu éternisée.

Je tiens encore à remercier FastConnect pour la salle, l’organisation, le buffet, etc.

En ce qui concerne le code des exemples, j’essaierai d’éditer ce post ultérieurement.

Edit Quelques liens en rapport :

Edit Le compte rendu de la soirée est maintenant dispo sur le site ALT.NET Fr. Merci Jb.

N’hésitez pas à me faire part de vos critiques positives, puisque les autres, constructives ou pas, elles vexent. OK ?

Posted in Posts Tagged: .NET, ALT.NET, AOP

ALT.NET en France : Présentation AOP à Paris le 17 juin

Romain Verdier — Tue, 02 Jun 2009 21:18:28 +0000

Avant toute chose : Non, je ne chercherai pas à justifier le rythme misérable de mes publications sur ce blog. Et non, je ne m’excuserai pas de tricher lamentablement en postant aujourd’hui quelque chose d’aussi, heu, bref.

Je voulais vous informer, ou plus probablement vous rappeler, que j’allais commettre une présentation sur l’AOP, le 17 juin, à l’occasion de la 14ème rencontre ALT.NET Parisienne. Vous trouverez les détails pratiques sur notre joli site. Merci à FastConnect qui sponsorise l’évènement.

Il va sans dire que je serais plus à l’aise s’il n’y avait que 3 personnes qui jugeaient bon de se déplacer. Pourtant, je vais m’asseoir sur cette considération et vous inviter à venir nombreux. Plusieurs fois au cours des rencontres précédentes nous avons abordé la question de la programmation orientée aspect lors des discussions libres, et il semblerait donc que le sujet rende curieux, à défaut de préoccuper. Peut-être mérite-t-il que nous lui fassions plus de place le temps d’une soirée. Je ne sais pas encore exactement quel sera l’agenda, mais l’idée est de présenter l’AOP en tant que concept, de le confronter gentiment aux paradigmes traditionnels, avant de passer plus concrètement à l’étude des différentes techniques et outils qui existent en .NET.

D’aucuns pourraient penser que le sujet n’est pas spécialement ALT.NET.

Ce à quoi je répondrais :

Certes, certes…

Enfin. Si on compte uniquement sur Microsoft pour profiter de l’AOP on risque assez rapidement de se sentir à l’étroit. Il est possible de faire de l’AOP sans sortir de la BCL, oui, et il est possible de faire de l’AOP un peu plus facilement en débordant sur EntLib. Cependant, les solutions les plus matures et les plus riches pour faire de l’AOP en .NET ne sont pas forcément estampillées Microsoft, ce qui risque de conduire l’utilisateur averti vers des frameworks plus spécialisés, open-source ou pas. Je veux parler de Castle.DynamicProxy, PostSharp, Linfu, Mono.Cecil, Spring.NET, etc.

Moi, je trouve que ça sent ALT.NET.

Bref, j’espère que cette rencontre verra naitre un débat et que nous pourrons collecter quelques retours d’expériences, comparer nos approches, bailler, etc. Encore une fois, toutes les infos sont disponibles sur le site altnetfr, à cette adresse.

Pensez à vous inscrire, et n’hésitez pas à faire passer l’info.

Posted in Posts Tagged: .NET, ALT.NET, Annonce, AOP

Petit rappel sur le Disposing Pattern en C#

Romain Verdier — Wed, 01 Apr 2009 09:02:14 +0000

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…

Quelques rappels

On parle de code managé en .NET car on fait implicitement référence au garbage collector qui gère automatiquement la mémoire. Il n’est pas question de faire un cours sur le GC, mais retenez juste qu’il est très intelligent, et qu’il est indépendant. Tellement indépendant qu’on ne peut pas prévoir quand est-ce qu’il va réellement effectuer son recyclage. Par exemple, lorsque vous écrivez :


public int Add(int a, int b)
{
    Calculator calculator = new Calculator();
    return calculator.Add(a, b);
};

Vous créez une nouvelle instance de Calculator qui sera référencée par la variable locale calculator. A la sortie de la méthode, la variable locale n’existe plus, et l’instance de Calculator n’est donc plus référencée. L’espace mémoire qu’elle occupe peut être récupéré, et le GC le sait. (Notez l’assonance.) Il y a un instant j’insistais sur l’indépendance du garbage collector : s’il sait qu’il peut libérer une instance, vous ne savez pas quand il le fera.

On considère que la collecte des miettes est indéterministe. Vous n’avez aucun moyen de savoir précisément quand le calculator que vous avez instancié précédemment sera collecté. Ca ne sera pas forcément à la sortie de la méthode, comme on pourrait naïvement s’y attendre ; ça peut être 47 ms ou 47 secondes après (pour caricaturer) et vous devriez même être heureux de ne pas avoir à vous en soucier.

Mais.

Tout n’est pas managé. Parfois, vous utilisez à partir d’objets managés des ressources non managées. Même si ça peut paraitre évident, il est bon de revenir là dessus. On parle de “ressource non managée” dans ce contexte pour décrire une ressource :

Dont l’allocation est déclenchée à partir de votre code managé.
Qui doit être libérée.
Mais dont le garbage collector n’est pas responsable.

Les handles de fichiers, les connexions de bases de données, les sockets réseau ou les références COM sont des exemples de ressources non managées.

Comment implémenter le disposing pattern

On se base sur l’interface IDisposable, et sur les destructeurs de C#. IDisposable expose une méthode Dispose, qui va détruire l’objet, et faire en sorte que sa mémoire soit désallouée du heap (et non pas de la pile comme je le vois souvent dans des blogs), surtout si on fait bien appel au mot clé using qui ne sert pas qu’à importer des namespaces.

Mais assez de théorie, passons au code. Imaginons la classe C# suivante, et regardons comment elle fait pour libérer le IntPtr qu’elle a en variable publique et qui constitue sa variable non managée dangereuse (attention aux memory leaks lol) :

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


public class MaClasseManagée : IDisposable // on implémente IDisposable
{
    private IntPtr m_Ressource_non_managée; // Attention !
	bool disposed = false; // pour savoir si la classe est libérée  

    public MaClasseManagée(IntPtr ptrnonmanagé)
    {
		if(ptrnonmanagé != null)
		{
			m_Ressource_non_managée = ptrnonmanagé; // allocation mémoire non managée
		}
		else // sinon
		{
			if (ptr.Equals(IntPtr.Zero) == true)
            {
                // on désalloue directement la mémoire du pointeur
				m_Ressource_non_managée = IntPtr.Zero
            }
			GC.CancelFullGCNotification(); // pas obligé, mais il vaut mieux
		}
    }

	public void FaireQuelqueChose()
	{
		// ici on utilise la ressource non managée qui a été allouée
		// ...
		// ...
	}

	// destruteur de la class
	~MaClasseManagée()
	{
		// partie un peu tricky : on interdit au CLR de supprimer l'instance
		// courante car ça a déjà été fait dans le Dispose d'IDisposable
		GC.SuppressFinalize(this);

		// on s'assure quand même qu'on garde pas de référence vers le pointeur
		m_Ressource_non_managée = IntPtr.Zero;
	}

	// methode dispose la plus importante
    public void Dispose()
    {
        if(!disposed)
        {
			// on appelle le garbage collector, et on force la libération de
			// tous les objets pour être certains de plus référencer des variables
			// non managées depuis C#
			GC.Collect();

			disposed = true; // déja disposé
        }
    }
}

Notez donc qu’il faut bien faire la différence entre le constructeur, le destructeur, et le dispose. Trop souvent les gens oublient l’un des trois, et compromettent du coup la sécurité de leur code.

A l’utilisation c’est simple :


// mot clé using
using(MaClasseManagée obj = new MaClasseManagée())
{
	// manipuler obj
	obj.FaireQuelqueChose();
}
// à la sortie du bloc using, le garbage collector est appellé et libère le tas
// des instances de MaClasseManagée persistantes, donc, forcément avec notre
// pattern, des ressources non managées IntPtr aussi

Et voilà :)

Je compte faire un article bientôt sur une nouvelle façon d’appréhender cette problématique avec l’AOP, notamment dans les architectures distribuées où il y a trop de code à écrire pour qu’on puisse se permettre de perdre du temps avec ces considérations bas niveau dans un contexte économique délicat (c’est la crise !) qui nous force à économiser le temps et l’argent sans pour autant arrêter de produire des logiciels de qualité qui donneront satisfaction au client et permettront aux développeurs de ne pas s’arracher les cheveux sur des solutions de 50 projets où les autres ont fait n’importe quoi et qu’il faut quand même livrer coute que coute tant pis pour les nuits blanches (ça serait quand même un comble de ne plus être en mesure de maitriser son métier, ou de devoir arrêter la qualité sous prétexte que c’est les chefs de projets qui décident des planning sans rien comprendre de la technique alors que c’est la base).

Posted in Posts Tagged: .NET, C#, WTF

Nouveau site pour ALT.NET France

Romain Verdier — Mon, 02 Mar 2009 10:21:03 +0000

Enfin ! Nous avions un groupe de discussion depuis le début, et nous squattions à droite et à gauche lorsqu’il était nécessaire de communiquer et de s’organiser, mais depuis quelques jours nous avons notre vrai portail. Un grand merci à Julien pour son travail, et à ceux qui ont commencé à contribuer à l’élaboration du contenu :

www.altnetfr.org

ALT.Net est un groupe de développeurs .NET passionnés, cherchant à améliorer la façon dont les logiciels sont développés. Nous reconnaissons qu’il n’y a pas de solution unique à un problème mais qu’il y a une multitude d’alternatives pouvant être appliquées dans différentes situations.

Le but était d’offrir une façade à la communauté ALT.NET de France. Jusqu’alors il fallait être spécialement motivé pour parvenir à comprendre ce qu’était ALT.NET, et encore un peu plus pour oser venir aux rencontres. Le nouveau site devrait donc répondre à ces deux besoins, en décrivant le mouvement et ses principes d’une part, et en proposant l’agenda des différents évènements que nous organisons d’autre part.

La dernière réunion a permis à Nicolas Roux et Frédéric Fadel de nous présenter Aspectize, et un compte rendu a déjà été posté par Gauthier. En Mars, il sera question de TDD, et c’est Djamel Zouaoui et Frédéric Schäfer qui animeront la présentation dans les locaux d’Octo. Nous comptons continuer de la sorte en annonçant les réunions futures et en proposant des comptes-rendus régulièrement. N’hésitez d’ailleurs pas à soumettre vos contributions ; un effort collaboratif ne peut qu’être profitable.

Pour ceux qui ne sont pas spécialement enclins à rédiger des comptes-rendus ou à proposer des articles, notez qu’il existe un wiki, qui offre déjà à tous la possibilité de participer sans contrainte particulière à l’enrichissement des ressources ALT.NET en français.

Bref, vous êtes chaudement invités à :

Ajouter altnetfr.org dans vos readers
Proposer vos comptes-rendus, vos articles, etc.
Venir à la prochaine réunion (et aux autres)
Faire passer le mot au sujet d’ALT.NET France !

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

Romain Verdier — Thu, 15 Jan 2009 00:08:29 +0000

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.

Méthodes varargs et interopérabilité

En C#, lorsqu’on veut définir une méthode à nombre de paramètres variables, on utilise la syntaxe suivante :


public static double Average(params int[] values)
{
    double sum = 0;
    foreach (var i in values)
        sum += i;
    return sum / values.Length;
}

Notez le mot clé params qui permet l’appel de la méthode en passant un tableau en paramètre, ou en listant plus librement les arguments :


var parameters = new int[]{45, 68, 97, 45};
ManagedClass.Average (parameters)
// ou bien
ManagedClass.Average (45, 68, 97, 45)

En C++ / CLI, la syntaxe est un peu différente mais le principe est le même :


double CodinglyInterop::CppCliLibrary::average(... array ^values)
{
	double sum = 0;
	for each (int i  in values)
		sum += i;
	return sum/values->Length;
}

C’est pareil, en plus moche. On utilise “...” au lieu de “params“, et l’appelant peut passer un tableau ou une liste d’arguments :


var parameters = new int[]{45, 68, 97, 45};
CppCliLibrary.average(parameters)
// ou bien
CppCliLibrary.average(45, 68, 97, 45)

Notez que l’interopérabilité entre C# et C++/CLI est native : les deux langages sont managés.

Et en C++ pas CLI, qu’est-ce que donnent les fonctions à nombre variable d’arguments ?

Bah c’est encore plus moche, et plus contraignant. Rappelez-vous :


extern "C" __declspec(dllexport) double average(int n, ...)
{
	double sum = 0;
	va_list args;
	va_start(args, n);
	for(int i=0 ;i < n; i++)
		sum += va_arg(args, int);
	va_end(args);
	return sum/n;
}

La principale différence est finalement assez subtile on n’utilise pas explicitement un tableau, mais on fournit un pointeur vers le début de la liste d’arguments. C’est à la méthode de se débrouiller (avec des macros) pour itérer, caster et s’arrêter lorsqu’il le faut. Généralement, un autre paramètre nommé de la méthode contient les infos nécessaires à cette opération. Dans l’exemple précédent, “n” est utilisé pour passer directement le nombre d’arguments de la liste. Dans printf, c’est la format string qui permet à la fonction de savoir combien d’arguments elle doit lire.

La question rigolote, puisque nous sommes dans le contexte d’un exemple rigolo, est la suivante :

Mais comment appeler les fonctions natives de ce genre depuis C# ? En utilisant pinvoke, probablement, mais plus précisément ?

Réponse : En pleurant. On est obligé de déclarer explicitement les imports pour chacune des utilisations que l’on va faire de la fonction dans notre code managé. En gros :


[DllImport ("NativeLibrary.dll")]
public static extern double average (int n, int i1);

[DllImport ("NativeLibrary.dll")]
public static extern double average (int n, int i1, int i2);

[DllImport ("NativeLibrary.dll")]
public static extern double average (int n, int i1, int i2, int i3);

[DllImport ("NativeLibrary.dll")]
public static extern double average (int n, int i1, int i2, int i3, int i4);

// Etc.

What a PITA, comme qui dirait… Mais c’est ici que l’ornithorynque nous sauve la vie. Car on peut écrire :


[DllImport ("NativeLibrary.dll", CallingConvention = CallingConvention.Cdecl)]
public static extern double average (int n, __arglist );

Et appeler la fonction ainsi :


NativeWrapper.average (4, __arglist (45, 68, 97, 45))

Hourra, donc. Mais quel est ce mot clé bizarre, __arglist, qui n’est même pas reconnu par Resharper ? Et bien il s’agit d’un des mots clés non documentés du langage, qui permettent principalement de jouer avec les TypedReference. Pour mieux comprendre ce qui se passe, essayons de réécrire en C# la méthode Average, sans utiliser le mot clé params, et en se reposant donc uniquement sur les “références typées”. On s’attaquera ensuite à la définition.


public class ManagedEvil
{
    public static double Average(__arglist)
    {
        double sum = 0;
        int count = 0;
        var iterator = new ArgIterator(__arglist);
        do
        {
            TypedReference typedReference = iterator.GetNextArg();
            sum += __refvalue( typedReference,int);
            count++;
        } while (iterator.GetRemainingCount() > 0);
        return sum / count;
    }
}

On note :

L’apparition du type ArgIterator, dont on crée une instance à partir de la liste d’arguments.
L’élément courant retourné par l’itérateur est une référence typée : TypedReference.
Un nouveau mot clé, __refvalue, permet d’extraire la valeur pointée par la référence.

Et tout ça compile, tout ça fonctionne, même si l’intérêt est limité.

`TypedReference`, `makeref`, `refvalue`, `__reftype`

Arrêtons les expériences pour décortiquer un peu plus sérieusement ce TypedReference. La MSDN définit ~~très clairement~~ la TypedReference :

Describes objects that contain both a managed pointer to a location and a runtime representation of the type that may be stored at that location.

Retenons qu’il s’agit d’une structure contenant :

Un pointeur managé vers un espace mémoire
Le type de ce qui est pointé en mémoire

Le meilleur endroit pour trouver des infos au sujet de TypedReference est finalement la spécification ECMA 335 du CIL. Je vous laisse fouiller, mais sachez que les bases sont notamment posées dans le paragraphe suivant (cf. 8.6.1.3):

La signature d’une référence typée est en fait représentée en tant que type valeur de base, comme les entiers ou nombres à virgule flottante. Dans la bibliothèque de classes du framework, le type est représenté par System.TypedReference, tandis que dans le langage intermédiaire il est désigné par le mot clé typedref. Ce type doit uniquement être utilisé pour les paramètres et les variables locales. Il ne peut ni être boxé ni être utilisé pour typer un champ, un élément de tableau, ou une valeur de retour de fonction.

Pour que je ne puisse jamais justifier l’intérêt de cet article, les gens chez Microsoft ont bien fait attention à exposer ce type le moins possible. Il est pourtant assez utilisé en interne, notamment dans System.Array, System.Threading.Interlocked, les services d’intérop (InteropServices) ainsi que dans certains overloads cachés utilisant les varargs (String.Concat, Console.WriteLine). A vrai dire, il semblerait que la raison officielle de son existence soit justement le support par le CLR des listes d’arguments, comme nous l’avons vu plus tôt. Il existe cependant un autre endroit (parmi d’autres) où son utilisation peut s’avérer intéressante : la réflexion via les FieldInfo. Mais avant d’y venir, regardons plutôt comment utiliser, très mécaniquement, TypedReference. On peut soit utiliser les mots clés interdits, soit – lorsque c’est possible – utiliser les quelques méthodes statiques de la classe TypedReference elle-même.

Création d’une référence typée : __makeref

Les références typées peuvent être obtenues pour des variables de n’importe quel type (référence ou valeur) à l’aide du mot clé __makeref.


int i = 42;
TypedReference typedReference = __makeref (i);

Ce mot clé dont l’usage n’est pas documenté correspond à l’instruction mkrefany en CIL. Le code intermédiaire correspondant à l’exemple précédant est le suivant :


int i = 42;

L_0000: ldc.i4.s 0x2a	/* push sur la pile d'un int32 = 42						*/
L_0002: stloc.0			/* sauvegarde dans la variable locale i					*/

TypedReference typedReference = __makeref(i);

L_0003: ldloca.s i		/* push sur la pile de l'adresse de i					*/
L_0005: mkrefany int32	/* push sur la pile de la référence typée				*/
L_000a: stloc.1			/* sauvegarde dans la variable locale typedReference	*/

La méthode statique TypedReference.MakeTypedReference permet aussi de créer des références typées, mais pas directement à partir d’une variable. Nous verrons un exemple d’utilisation dans la dernière partie de l’article.

Récupérer et/ou modifier la valeur : __refvalue

Une fois qu’on a une référence typée, il est possible de lire et/ou d’écrire la valeur référencée en utilisant le mot clé __refvalue. Il est visuellement assimilable à un appel de fonction à deux paramètres, dont le premier serait la TypedReference, et le second le type de la valeur référencée. En l’utilisant à droite d’une affectation, on lit la valeur, et en l’utilisant à gauche d’une affectation, on écrit la valeur. Assez troublant…


int i = 42;
TypedReference typedReference = __makeref(i);
int j = __refvalue (typedReference, int);
__refvalue (typedReference, int) = 24;

Encore une fois, il est possible de mapper son utilisation avec un opcode spécifique, refanyval :


int i = 42;
TypedReference typedReference = __makeref(i);

L_0000: ldc.i4.s 0x2a	/* push sur la pile d'un int32 = 42						*/
L_0002: stloc.0			/* sauvegarde dans la variable locale i					*/
L_0003: ldloca.s i		/* push sur la pile de l'adresse de i					*/
L_0005: mkrefany int32	/* push sur la pile de la référence typée				*/
L_000a: stloc.1			/* sauvegarde dans la variable locale typedReference	*/

int j = __refvalue (typedReference, int);

L_000b: ldloc.1			/* push sur la pile de la typedReference				*/
L_000c: refanyval int32 /* push sur la pile de l'adresse de la référence        */
L_0011: ldind.i4		/* déréférencement et push sur la pile de la valeur		*/
L_0012: stloc.2			/* sauvegarde dans la variable locale j					*/

__refvalue (typedReference, int) = 24;

L_0013: ldloc.1			/* push sur la pile de la typedReference				*/
L_0014: refanyval int32 /* push sur la pile de l'adresse de la référence        */
L_0019: ldc.i4.s 0x18	/* push sur la pile d'un int32 = 24						*/
L_001b: stind.i4		/* sauvegarde de la valeur à l'adresse de la référence  */

La méthode TypedReference.ToObject permet aussi de déréférencer la TypedReference et d’obtenir sa valeur, boxée.

Récupérer le type : __reftype

Enfin, il est possible de récupérer l’information de type associée à la TypeReference, en utilisant un dernier mot clé __reftype.


int i = 42;
TypedReference typedReference = __makeref(i);
Type type = __reftype(typedReference);

Là encore, on peut faire correspondre __reftype à l’opcode refanytype :


int i = 42;
TypedReference typedReference = __makeref(i);

L_0000: ldc.i4.s 0x2a	/* push sur la pile d'un int32 = 42						*/
L_0002: stloc.0			/* sauvegarde dans la variable locale i					*/
L_0003: ldloca.s i		/* push sur la pile de l'adresse de i					*/
L_0005: mkrefany int32	/* push sur la pile de la référence typée				*/
L_000a: stloc.1			/* sauvegarde dans la variable locale typedReference	*/

Type type = __reftype(typedReference);

L_000b: ldloc.1			/* push sur la pile de la typedReference				*/
L_000c: refanytype		/* push sur la pile du type token de la référence		*/
L_000e: call class Type::GetTypeFromHandle(RuntimeTypeHandle)
L_0013: stloc.2			/* récupération et sauvegarde du Type à partir du token */

Notons que la méthode statique TypedReference.GetTargetType est l’équivalent autorisé de __reftype, et qu’il existe aussi la méthode TypedReference.TargetTypeToken qui retourne le handle du type sous la forme d’un RuntimeTypeHandle. La version light, en somme.

Rien de très impressionnant ; d’ailleurs vous pouvez retourner sur youtube car la suite n’est pas mieux. Mais je persiste !

Un autre exemple : `GetValueDirect` et `SetValueDirect`

Je vous disais tout à l’heure que j’avais trouvé un exemple d’utilisation dans lequel on pouvait faire intervenir les TypedReference. Il s’agit de la lecture écriture des champs par réflexion, et plus particulièrement des champs de type valeur. Et encore plus particulièrement lorsqu’ils sont imbriqués.

Prenons pour exemple ce modèle simpliste :


public struct Person
{
	public Address Address;
}

public struct Address
{
	public City City;
}

public struct City
{
	public int ZipCode;
}

Il est important de bien noter que Person, Address, City et ZipCode sont des value types. Si on veut inspecter une instance de Person par réflexion, jusqu’à lire le ZipCode de son adresse, on va écrire quelque chose comme :


// On a une instance de Person
var p = new Person();
p.Address.City.ZipCode = 75000;

// On récupère les FieldInfo
var addressField = typeof(Person).GetField("Address");
var cityField = typeof(Address).GetField("City");
var zipCodeField = typeof(City).GetField("ZipCode");

// On chaine les appels à FieldInfo.GetValue pour inspecter la Person
// et lire la valeur du ZipCode
var zipCode =  (int)zipCodeField.GetValue(cityField.GetValue(addressField.GetValue(p)));

Ca fonctionne, mais le boxing a tué mon hourra. GetValue prend un object en argument, et retourne un object, alors qu’on travaille ici sur des types valeurs… En lisant la dernière ligne de droite à gauche :

p va être boxé pour être passé en paramètre à GetValue
addressField.GetValue va boxer la valeur du champ Address pour le retourner sous la forme d’un object
cityField.GetValue va boxer la valeur du champ City pour le retourner sous la forme d’un object
zipCodeField.GetValue va boxer la valeur du champ ZipCode pour le retourner sous la forme d’un object
Le cast en int effectue l’ultime et nécessaire unboxing

Pas terrible…

Heureusement, il existe sur FieldInfo la méthode GetValueDirect, qui prend en paramètre une TypedReference !

Si on peut directement récupérer une référence typée sur le ZipCode, on peut éviter quelques emboitages :


var p = new Person();
p.Address.City.ZipCode = 75000;
FieldInfo zipCodeField = typeof(City).GetField("ZipCode");
var zipCode = (int)zipCodeField.GetValueDirect(__makeref (p.Address.City));

Seulement, on change les contraintes, car la création de la référence typée de cette façon implique alors que l’on connaisse Address et City au design time. Qu’à cela ne tienne : il existe la méthode statique TypedReference.MakeTypedReference évoquée plus tôt, qui permet de construire une référence typée à partir d’une target et d’un tableau de FieldInfo correspondant à l’inspection désirée de l’espace mémoire réservé par p :


var p = new Person ();
p.Address.City.ZipCode = 75000;
var addressField = typeof (Person).GetField ("Address");
var cityField = typeof (Address).GetField ("City");
var zipCodeField = typeof (City).GetField ("ZipCode");

TypedReference r = TypedReference.MakeTypedReference (p, new[] {addressField, cityField});
var zipCode = (int) zipCodeField.GetValueDirect (r);

Dans ce cas précis, les performances mesurées sont environ 4 fois meilleures en utilisant GetValueDirect à la place de GetValue. Hourra.

Quant à l’écriture, nous n’avons même pas le luxe du choix, puisque chainer les SetValue ne peut en aucun cas modifier la personne, cette fonction retournant à chaque fois une copie des valeurs… Il faut donc nécessairement utiliser SetValueDirect et une TypedReference.

Conclusion

La conclusion, que je vous dois brève :

Ce qui n’est pas documenté ne doit pas être utilisé. En gros, tout ce qui est lié aux arglists est à oublier. En revanche, la création et la manipulation de TypedReference sans passer par tous les __mots __clés __moches n’est pas réprouvée. Notez simplement que TypedReference n’est pas CLS Compliant.

Posted in Articles Tagged: .NET, C#, CIL, Optimisation

Dégage, sale programmeur !

Romain Verdier — Mon, 29 Dec 2008 23:35:29 +0000

Et ouais, être développeur lorsqu’on a plus de 30 ans en France, c’est pire que d’être caissier à 40 ans. La plupart des gens qui passent 90% de leur temps à programmer vont s’arranger pour qu’on les voit comme des ingénieurs d’études, des experts techniques, des chefs de projets, des architectes solution, des consultants, etc. Le top, quand on est un pauvre prestataire d’une SSII en mission pour une banque, et que l’on passe ses journées à coder, c’est de raconter à tout le monde qu’on est INGENIEUR DANS LA FINANCE. Oui oui.

C’est assez terrible, mais il semblerait qu’on n’y puisse pas grand chose.

La première observation, c’est que le phénomène est assez localisé. Ou plutôt : le phénomène n’est pas généralisé. En France, dès les études, on explique qu’il y a les développeurs (berk), et les chefs (ouais).

Bon, les enfants, si vous avez été admis chez SUPIMAG, c’est pas pour finir développeur. En sortant de notre établissement, espérez être chef de projet junior (à la tête de 5 développeurs, 52K€, pendant 6 à 12 mois), puis, évidemment directeur de projet (1200 développeurs à vos pieds, 420K€ + iPhone + bonus)

Et ensuite, même si on se fout de votre gueule lors des premiers entretiens, c’est trop tard : vous ne voulez plus, vous ne pouvez plus être développeur. On pourrait vous confondre avec l’admin réseau (BTS Informatique et Réseaux pour l’Industrie et les Services Techniques, 23K€, Nokia 3310 pour les astreintes).

Aux Etats-Unis, par exemple, et sans doute ailleurs, ça ne fonctionne pas comme ça. Il y a différents métiers. Développeur, c’est un métier. Manager, c’est un autre métier. Le développeur programme, et le manager gère. Il est tout à fait possible de rester programmeur lorsqu’on devient papa. On n’est pas pris pour un con, juste pour un programmeur senior, payé et reconnu comme tel. Un professionnel ayant fait un choix de carrière plutôt qu’un autre, en somme. Il n’y a pas une hiérarchie dans laquelle le programmeur est en bas de l’échelle, il y a juste différents métiers dont les exercices sont nécessaires à la réalisation des projets informatiques.

Tant qu’on ne comprendra pas ça ici, on continuera à subir les rires bruyants des gros blaireaux qui parlent de pissage-de-code-lol.

Gens, vous vous trompez.

Le développement, ou l’ingénierie logicielle si on veut élargir un peu, est une discipline complexe, qui requiert un cerveau. Un développeur digne de ce nom est une personne capable de réfléchir, de conceptualiser, de comprendre. C’est une personne capable de travailler en équipe, de communiquer efficacement, de s’organiser. C’est une personne qui ne peut pas se reposer éternellement sur ses acquis. C’est aussi une personne qui doit produire, et qui peut difficilement tricher. Programmer est un métier à la fois compliqué et passionnant, dont on peut même penser qu’il demande du talent. En fait, c’est probablement l’un des métiers les plus exigeants et intelligents qui soient.

Il est presque incompréhensible qu’on en soit arrivé à trouver ça péjoratif, et que la programmation ait été reléguée au rang de tâche honteuse.

Programmeur : n.m. Celui dont le métier est de rédiger des programmes informatiques. Le plus souvent, jeune diplômé, ou chef de projet raté. Syn. looser. Ex. Tu crains comme un programmeur.

Première hypothèse : Romain, t’es un crétin doublé d’un parano : personne n’a cette sale image des développeurs. Deuxième hypothèse – très personnelle et probablement très discutable : tout le monde n’est pas né pour être programmeur. Et tant mieux, devrais-je ajouter : il serait assez triste de rêver du contraire. Cependant, il y a un besoin de programmeurs, en France comme ailleurs, et donc, on obtient fatalement une armée de développeurs-malgré-eux. Ni particulièrement doués ni particulièrement motivés, il se retrouvent à devoir maintenir des applications plus ou moins monstrueuses, sans vraiment comprendre ce qu’ils font et sans avoir envie d’ailleurs d’en comprendre plus. Développer, pfiou, c’est finalement un peu relou, hein. Vivement que je puisse moi aussi passer mes journées sur Powerpoint.

Ce que je veux dire, c’est que dans le fond, il y a peu de personnes qui savent ce qu’est la programmation. Parmi les programmeurs, les chefs, les recruteurs, les profs, les chats, ma mère. Moi, plus par fausse modestie que pour paraphraser Socrate, j’ai découvert il n’y a pas si longtemps que je ne savais pas vraiment ce qu’était la programmation.

Bon, j’exagère un peu pour que vous souriez, mais au delà de la simplification volontairement naïve et de la provocation facile, je crois qu’il y a un peu de vrai. Quand la Masse se met d’accord sur une définition faussée du métier de programmeur, les choses sont vite réglées. A côté de ça, il y a des développeurs “qui ont goûté au sang” (© Jb) et qui ont du mal à revenir aux Taillefine “Pruneau” 0%. Tant qu’à faire, ne confondez pas tout le monde et choisissez bien votre audience le jour où vous voulez expliquer que vous aimez programmer, ou pire, que vous êtes capable d’en tirer une certaine fierté.

Au fait, ça existe les architectes qui écrivent juste les prototypes des méthodes et qui laissent l’implémentation aux programmeurs ?

Posted in Posts Tagged: Opinion

Cecil.Decompiler : Un décompilateur .NET OpenSource

Romain Verdier — Tue, 16 Dec 2008 22:23:30 +0000

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.

Déjà, belle surprise en recevant le mail d’invitation de Jb… Nous ne nous étions croisé qu’une soirée, à Paris, lorsqu’il était venu présenter Mono en novembre pour une de nos réunions ALT.NET. Dans un milieu où le copinage reste bien présent, ce genre de proposition dénote bien une certaine ouverture d’esprit, et un fort degré de coolitude. Merci. Robert Pickering faisait aussi partie des invités mais à part lui (et Jb, donc) je ne connaissais personne. Ce fut l’occasion de faire la connaissance de Patrice Lamarche, Mathieu Szablowski, Vincent Bourdon, et Sébastien Lebreton (auteur de réflexil). Sept personnes en tout ; soit un petit comité.

Je vous avouerai que j’étais un peu impressionné à l’idée de devoir rejoindre tout ce beau monde pour travailler sur un projet de cette envergure, dont la complexité moyenne dépasse quand même celle d’une application de gestion classique… Mais l’ambiance était excellente d’une part, et le sujet carrément intéressant d’autre part.

Ca ne suffit pas pour faire oublier qu’on est en train de faire du pair programming avec un mec de l’équipe Mono, mais ça aide un peu. En tout cas, ça fait vraiment plaisir de participer à un projet aussi motivant, avec des gens dont la simple proximité rend moins con. J’aurais aimé pouvoir travailler en pair avec tout le monde, mais j’ai principalement codé avec Jb et Rob. Et tout seul aussi, hein. Je n’ai pas envie de rentrer dans les détails techniques aujourd’hui, mais en gros, j’ai principalement travaillé sur la partie “décompilation C#”, et plus particulièrement sur les étapes de transformation de l’arbre syntaxique visant à faire apparaitre les structures de haut niveau du langage.

Le decompiler lit le code intermédiaire, en infère un Control Flow Graph, puis un AST assez brut dans lequel, par exemple, toutes les pre/post-tested loops sont modélisées sous la forme de statements while/do-while. Selon le langage, et selon la version du langage, il faudra ensuite exécuter une série d’analyses et de transformations sur cet arbre afin de reconnaitre les constructions spécifiques. Par exemple, et au hasard, le foreach.

Dans un vieux post, j’expliquais que le foreach en C# était syntaxiquement équivalent à :


IEnumerator enumerator = jambons.GetEnumerator();
try
{
	while( enumerator.MoveNext())
	{
		Jambon jambon = enumerator.Current;
		// Manger le jambon, miam, etc.
	}
}
finally
{
	IDisposable disposableEnumerator = enumerator as IDisposable;
	if(disposableEnumerator != null)
	{
		disposableEnumerator.Dispose();
	}
}

C’est donc le pattern qu’il faut identifier dans l’arbre, à quelques subtilités près. Ca m’a pris 3 bons jours, et c’est loin d’être terminé si on veut gérer tous les edge cases, allez donc savoir pourquoi. J’ai aussi travaillé avec Jb sur une implémentation sympa d’un “pattern matching du pauvre” en C#, joyeusement supprimée depuis… On cherche quelque chose de mieux. Mais ça permettait d’écrire des trucs rigolos du genre :


// Création du pattern
var matcher = Pattern.Match()
					 .Is()
                     .Select(mie => mie.Method)
                     .Is()
                     .Tag(() => method_key, mre => mre.Method)
                     .Tag(() => target_key, mre => mre.Target);

// Compilation du pattern matcher pour récupérer un delegate qui pourra être mis en cache
// et invoqué avec de bonnes performances
var methodInvocationMatcher = matcher.Compile> ();

// Exécution du pattern matching : on obtient un MatchResult
var result = Pattern.Run (MethodInvocationMatcher, expression);

// On peut maintenant, en cas de succès, travailler avec les valeurs qui ont été tagguée
// lors du pattern matching, si elles ont été trouvées
if (result.Success)
{
	Expression targetExpression;
    if (result.TryGetValue(target_key, out targetExpression))
    {
		// ...
	}

	MethodReference methodReference;
	if (result.TryGetValue(method_key, out methodReference))
	{
		// ...
	}
}

Le code du matcher pouvait être généré dynamiquement via System.Reflection.Emit, puis compilé pour obtenir un delegate capable d’être exécuté sans ruiner les perfs. Ca peut vous rappeler quelque chose… mais l’idée n’était pas de moi !

J’ai également eu l’opportunité de travailler avec Rob pour réaliser une version F# du matcher capable de détecter les foreach à titre d’essai. Pas vraiment l’initiation idéale à F# pour un profane comme moi, mais heureusement Rob a gardé le clavier durant la session. Ce fut pour moi l’occasion d’avoir un bon aperçu de la puissance du langage en matière de pattern matching et de tester rapidement pour la première fois l’intérop C#/F#.

Le projet en lui-même est à mon sens prometteur. Ce n’est pas juste un Reflector-bis. Il s’agit d’un framework de décompilation, libre et open source, qui peut être embarqué n’importe où. Ca ouvre pas mal de perspectives pour ceux qui travaillent sur des outils d’analyse statique de code par exemple. Jason Bock, auteur de CIL Programming avec lequel j’ai été méchant par le passé, va même jusqu’à trouver Cecil.Decompiler et sa licence MIT/X11 rassurants dans la mesure où la visibilité sur le devenir de Reflector est compromise.

Je ne suis pas sûr de vouloir crier hourra pour ça, mais ce dont je suis sûr, c’est que pouvoir disposer d’un décompilateur .NET open source, managé, qui repose sur une base solide, c’est tout bon. Si on considère en plus que Sébastien est déjà lancé à fond sur la réalisation d’une interface pour exploiter Cecil.Decompiler, dont le modèle d’extensibilité devrait être plus souple que celui de Reflector, c’est encore plus alléchant.

Quoi qu’il en soit, le decompiler en est à ses débuts. Il reste vraiment beaucoup de choses à faire, et ce à plusieurs niveaux :

Core
Support des langages : C#, VB, F#, etc.
Interface, plugins

Mais au moins, vous savez à présent que le projet existe.

Posted in Posts Tagged: .NET, Annonce, C#, Cecil.Decompiler, Expression Tree

Le futur de C# ?

Romain Verdier — Sat, 15 Nov 2008 15:34:03 +0000

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.

J’aurais carrément ajouté un “lol” à la place du point, moi. Difficile dans ces conditions de comprendre de quoi est fait C# 4.0, difficile d’anticiper à quoi pourront ressembler les prochaines versions. Pourtant, et c’est où je veux en venir, Anders Hejlsberg a été particulièrement clair dans sa présentation. Il a parlé du langage C#. Il a exposé sa vision, celle de l’équipe de conception du langage. Je vous invite donc tous à voir sa session si ce n’est déjà fait, en prenant bien soin de ne pas zapper l’introduction.

C# est né avec et pour la plateforme .NET. On peut être surpris de se faire rappeler que ça fait 8 ans qu’il a été annoncé pour la première fois, et presque 10 ans que sa conception a commencé. Pourtant, si on met de côté les spécificités héritées de la plateforme .NET elle-même, c’est un langage dont le vrai caractère n’a commencé à s’affirmer qu’à partir de la version 3.0, avec laquelle sont apparus, entres autres, les expressions lambda, les arbres syntaxiques, les méthodes d’extension, ou Linq – ce dernier reposant d’ailleurs essentiellement sur les précédentes features.

On a un peu tout vu et entendu à leur sujet : de la critique violente à l’apologie extatique. Pourtant, on ne parle que d’un langage de programmation. Il y a souvent plusieurs raisons de critiquer un langage, et bien évidemment, toutes ne se valent pas. Essayer de discuter les choix des concepteurs quant à l’implémentation de telle ou telle feature, pourquoi pas :

Ouais, mais tu vois, ça ils auraient dû le descendre au niveau du CLR au lieu de laisser le compilo interpréter des attributs pourris

Quoique déjà, il vaut mieux ne pas s’appeler Romain Verdier et avoir réfléchi un peu plus de 3 minutes à la pause café. Car remettre en cause aussi légèrement les décisions prises par une équipe qui ne ressemble pas exactement à un groupe de singes, ça revient à parler pour parler.

Attention, tout le monde peut avoir un avis, et l’équipe d’Anders n’est probablement pas infaillible. ce n’est pas parce qu’on ne sait pas peindre qu’on est obligé d’aimer tous les tableaux, hein. Je suis simplement bien placé pour savoir que les opinions-réflexes sont parfois assez dures à réfréner, et rarement pertinentes.

Bref, ne critiquez plus jamais C#, OK ?

OKAY ?

Hihi. Non, j’ai surtout envie d’insister sur un point précis, ou sur une critique particulière, celle qui consiste à regretter ouvertement l’extension du “périmètre C#”, si possible avec condescendance. Critiquer un langage parce qu’il mêle différents concepts, parce qu’il s’enrichit et se diversifie en introduisant des fonctionnalités que l’on peut difficilement classifier ; ça n’a pas vraiment de sens pour moi.

Aujourd’hui, on peut considérer que C#, à l’instar d’autres langages, est un langage multi-paradigmes :

Impératif
Orienté objet
Générique
(Fonctionnel)
(Dynamique)

Et, à la différence d’autres langages, il évolue très vite.

Je me permets de citer Eric Lippert :

The techniques are not good in of themselves, they’re good because they’re practical.

Perhaps surprisingly, our goal in making C# is not to make an object-oriented language. Our goal is to make a compelling and practical language for general-purpose application development on our platforms, and thereby enable our customers to be successful. Making an object-oriented language called C# is just a means to that end, not an end in of itself.

Le paragraphe est tiré de son article en plusieurs parties au sujet du futur de C#. (Je vous invite à le lire, évidemment.) Il y explique assez bien que le but du langage est d’être un langage pratique, puissant, efficace. Et si les méthodes d’extension rendent Linq possible, alors, même si elles n’ont rien à voir avec l’OOP, il serait peut-être bon de les ajouter au langage. De même, si l’inclusion du DLR dans .NET 4 et son exploitation à partir de C# via le mot clé dynamic permet de rendre l’interopérabilité entre C# et les langages dynamiques possible et même facile, alors ce n’est probablement pas complètement con. Python, Ruby, Javascript, COM, etc. Ce n’est pas comme si l’essence même du langage changeait pour que ce dernier supporte nativement, heu, le parsing des fichiers CSV par exemple.

Il y a aussi les alarmistes, qui pensent tout de suite que telle ou telle fonctionnalité, potentiellement dangereuse va être détournée. Les mauvais programmeurs vont en abuser et rendre la vie des bons programmeurs (ceux qui passent leur temps à corriger et maintenir le travail d’autrui) insupportable. Perso, je préfère reprendre un projet .NET 2.0 de 200K LOC, plutôt qu’un projet .NET 1.1 de 50K LOC. Et il y a fort à parier pour qu’en 2010, je préfère maintenir une solution .NET 4.0 plutôt qu’une solution .NET 2.0. L’inférence de type et les méthodes d’extensions faisaient peur en C# 3.0, mais je me demande dans quelle mesure on en a abusé dans les projets-du-monde-réel. Je n’ai pas assez d’éléments pour juger – vos retours d’expérience m’intéressent – mais je vais quand même y aller de mon pronostic : les exagérations doivent être minoritaires. En ce qui concerne le late-binding en C# 4.0, pour prendre un exemple plus récent, je ne vois pas qui serait prêt à perdre le confort de la complétion et du typage statique pour utiliser le mot clé dynamic sans raison. Mais peut-être me trompè-je ; nous verrons bien.

Quoi qu’il en soit, il est selon moi important de prendre un peu de recul. Le langage est un outil, un moyen. Il fut un temps où la meilleure façon d’arriver à de se faire tabasser dans la rue consistait à porter un t-shirt “I love JavaScript”. De nos jours, c’est devenu le meilleur moyen de choper. On se demande bien pourquoi…

Je crois qu’il faut vraiment voir ça comme un enrichissement du langage. Je ne parle pas des t-shirts, mais de l’apparition de toutes ces fonctionnalités a priori éloignées du couple OO/Imperative Programming dans un langage à accolades. Que penser alors de la possible promotion accordée à la métaprogrammation pour C# 5.0 ? OK, ce n’est pas nouveau et dans une certaine mesure il est déjà possible d’y recourir maintenant, mais exposer le “compiler as a service” comme l’a laissé entendre Anders à la fin de son talk, c’est un choix non-orthodoxe, et un peu plus ambitieux. Le ton semble avoir été donné : C# va probablement se décomplexer de plus en plus et surprendre encore en offrant ce que d’autres langages plus rigides s’interdiraient d’offrir. C’est en tout cas mon sentiment.

Jusqu’à présent, j’ai eu l’impression qu’à chaque nouvelle version du langage les évolutions s’inscrivaient avec une certaine cohérence dans ce qui semble être une vision pragmatique de C# et de la plateforme .NET. Au risque de paraitre complètement vendu, je n’ai pour l’instant pas été sérieusement contrarié ou déçu dans l’histoire C#.

Parmi ceux qui pouvaient crier au scandale en découvrant les expressions lambda ou Linq lors de la sortie de C# 3.0, j’aimerais bien avoir les noms de ceux qui ne peuvent plus s’en passer aujourd’hui, et qui commencent déjà à crier au scandale en voyant poindre le duck typing…

Posted in Posts Tagged: .NET, C#

Introduction à Mono.Cecil : Implémenter INotifyPropertyChanged

Romain Verdier — Mon, 10 Nov 2008 19:20:09 +0000

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…

Même si la plupart du temps vous préfèrerez sans doute bénéficier de l’abstraction offerte par les outils d’AOP classiques, vous trouverez peut-être excitant de jouer avec Cecil pour déveloper des aspects bas niveau en mettant les mains dans le camboui. (Vous pouvez aussi trouver ça naze au point d’en bailler, hein.)

Bref, ce post va plus ressembler à un article sur Cecil qu’à un article sur INotifyPropertyChanged. Il y aura probablement deux parties, mais ce n’est pas une promesse :

Part 1 : première version d’un transformer utilisant Cecil pour implémenter INotifyPropertyChanged (cet article)
Part 2 : version améliorée du transformer lançant l’évènement de notification uniquement lorsque la valeur affectée à la propriété est différente

Eventuellement, je fournirai quelques pistes pour lancer automatiquement ce genre de transformations en post-build dans la seconde partie, si seconde partie il y a.

Mais commençons par le commencement, en prenant pour victime la Person des articles précédents. Le but est de pouvoir écrire :


	[NotifyPropertyChanged]
	public class Person
	{
		private string name;

		public string Name
		{
			get { return this.name; }
			set { this.name = value; }
		}
	}

et d’obtenir au final une classe Person implémentant INotifyPropertyChanged et capable donc de notifier par l’événement PropertyChanged les changements de ses propriétés.

Cecil permet de charger un assembly, de l’inspecter et de le modifier éventuellement avant de le sauvegarder, de le copier, etc. L’idée consiste donc à :

Compiler le code ci-dessus normalement, afin d’obtenir un assembly
Lancer un transformer, qui utilise Cecil afin de charger cet assembly
Modifier l’assembly, toujours avec Cecil, pour y injecter l’implémentation d’INotifyPropertyChanged en manipulant le code CIL.
Sauvegarder l’assembly modifié

Le transformer

Dans cette première version, imaginons quelque chose de naïf : un programme en ligne de commande, qui prend en argument le chemin de l’assembly à instrumenter :


    private static void Main(string[] args)
    {
        if (args.Length == 0)
        {
            Console.WriteLine("Usage: transformer ");
            return;
        }
        new Transformer(path).Run();
    }

D’ailleurs, je vais continuer à être naïf en laissant de côté la gestion du logging, des exceptions, etc. Les snippets présentés ici n’en seront que plus lisibles, à défaut d’être solides.

Commençons par une vue d’ensemble des étapes nécessaires à la transformation des assemblies, que nous détaillerons ensuite. (Vous aimez les opcodes ?)

Chargement de l’assembly à instrumenter
Identification des types à modifier : on recherche ceux qui sont taggés par notre attribut [NotifyPropertyChanged]
Transformation de chacun de ces types pour leur faire supporter INotifyPropertyChanged
Sauvegarde de l’assembly modifié

Le schéma ci-dessous met en avant les différentes étapes de la transformation :

[#1] Implémentation proprement dite de l’interface INotifyPropertyChanged
[#2] Ajout d’une fonction “helper” pour le déclenchement de l’évènement PropertyChanged
[#3] Instrumentation des setters, en utilisant la méthode précédente pour lancer les notifications

Voyons comment implémenter ça. Rappelez-vous, tout commence par :


	new Transformer(path).Run();

Le constructeur (qui en fait sans doute un peu trop) :


public Transformer(string assemblyPath)
{
    this.assemblyPath = assemblyPath;
    this.assembly = AssemblyFactory.GetAssembly(assemblyPath);
    this.assembly.MainModule.LoadSymbols();
    this.assembly.MainModule.FullLoad();
}

Assez trivial : on laisse tout le travail à Cecil. Son AssemblyFactory nous permet de récupérer la définition de l’assembly à modifier. Afin de conserver les sequence points et permettre de debuguer l’assembly modifiée, on charge les infos de debug. L’appel à la méthode FullLoad permet de charger en mémoire toute la représentation du module principal, afin de pouvoir la modifier par la suite.

Petite parenthèse introductive : Plusieurs fois, dans les méthodes que je vais présenter par la suite, on aura besoin de récupérer une TypeReference, à partir d’un Type. Lorsque ce sera le cas, on utilisera une des deux méthodes suivantes :


private TypeReference GetReference(Type type)
{
    TypeReference typeReference = this.assembly.MainModule.TypeReferences[type.FullName]
                                  ?? this.assembly.MainModule.Import(type);
    return typeReference;
}

private TypeReference GetReference()
{
    return GetReference(typeof (T));
}

Leur fonctionnement est simple : si on a déjà chargé le type dans le module principal de l’assembly en cours de modification, on retourne directement la TypeReference correspondante, sinon on importe le type pour créer la référence. Car Cecil fait bien la distinction (qui existe au niveau CIL) entre les définitions et les références pour les différents éléments du code (types, fields, methods, etc.)

Lorsqu’on veut modifier une méthode, par exemple, on va travailler sur sa définition. Mais si on désire simplement l’appeler, il nous faut juste sa référence. Ce modèle, plus juste que celui proposé par l’API de réflexion de la BCL peut sembler troublant au premier abord, mais s’avère au final plus puissant puisqu’il colle directement avec les spécifications du langage intermédiaire. Fin de la parenthèse.

Bien, on a de quoi commencer l’autopsie du Transformer, dont le nom est plus que douteux… La méthode Run semble être un point de départ judicieux pour notre analyse :


public void Run()
{
    foreach (TypeDefinition type in GetTypesToWeave())
    {
        MethodReference firePropertyChangedMethod = WeaveINotifyPropertyChanged(type);
        WeaveEventTriggers(type, firePropertyChangedMethod);
    }
    this.assembly.MainModule.SaveSymbols();
    AssemblyFactory.SaveAssembly(this.assembly, this.assemblyPath);
}

La méthode GetTypesToWeave permet de retourner tous les types à modifier, c’est à dire ceux qui sont décorés par notre attribut [NotifyPropertyChanged]. Ce dernier devra donc être défini dans un assembly quelconque, référencé à la fois par le code client – celui qui contient les types à instrumenter – et par notre transformer. Chacun des types est ensuite transformé par les appels successifs aux méthodes WeaveINotifyPropertyChanged et WeaveEventTriggers.

La sauvegarde des modifications s’effectue elle aussi en plusieurs étapes :

On indique qu’on souhaite conserver les symboles de debugging
On sauvegarde notre travail en remplaçant l’assembly original par celui que l’on vient d’instrumenter.

Jusqu’ici, tout va bien, comme qui dirait. Mais creusons un peu plus. Tout d’abord, le code de la méthode GetTypesToWeave qui nous permet de retourner les types de l’assembly à modifier. Il s’agit essentiellement d’alléger la méthode Run en évitant les imbrications et en isolant la logique de recherche dans une autre méthode :


private IEnumerable GetTypesToWeave()
{
    string attributeFullName = typeof (NotifyPropertyChangedAttribute).FullName;
    foreach (TypeDefinition type in this.assembly.MainModule.Types)
    {
        foreach (CustomAttribute attribute in type.CustomAttributes)
        {
            if (attribute.Constructor.DeclaringType.FullName == attributeFullName)
            {
                yield return type;
                break;
            }
        }
    }
}

Notez qu’on utilise pour cela un bloc itérateur. Le reste pourrait se passer de commentaire : on retourne les types marqués par l’attribut [NotifyPropertyChanged] en basant la recherche sur le fullname des attributs.

Passons maintenant à la modification des types. Rappelez-vous, il y a deux étapes principales :

Implémentation de INotifyPropertyChanged (méthode WeaveINotifyPropertyChanged)
Instrumentation des setters (méthode WeaveEventTriggers)

Implémentation de `INotifyPropertyChanged`

L’implémentation proprement dite de INotifyPropertyChanged est une tâche que l’on peut aisément redécomposer. Cette redécomposition est d’ailleurs assez visible dans la méthode WeaveINotifyPropertyChanged que je propose :


private MethodReference WeaveINotifyPropertyChanged(TypeDefinition type)
{
    TypeReference iNotifyPropertyChangedType = GetReference();
    type.Interfaces.Add(iNotifyPropertyChangedType);
    FieldReference eventField = WeaveEvent(type);

    return WeaveEventFiringHelper(eventField, type);
}

La première étape consiste à récupérer une TypeReference correspondant à cette interface pour l’ajouter à la liste des interfaces du type que l’on modifie. Simple, mais insuffisant : il faut également implémenter l’interface. Dans le cas d’INotifyPropertyChanged, on doit ajouter un évènement public PropertyChanged au type. C’est la méthode WeaveEvent qui s’en chargera. (Etape [#1] du schéma)

La méthode WeaveEventFiringHelper, quant à elle, permet d’ajouter une méthode FirePropertyChanged au type. Quelque chose équivalent à :


    private void FirePropertyChanged(string propertyName)
    {
        if (PropertyChanged != null)
        {
            PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
        }
    }

C’est l’étape [#2] de la transformation, également signalée dans le schéma précédent. La référence vers cette méthode est retournée pour permettre son appel plus tard à partir des setters des propriétés.

Dès que vous aurez terminé de bailler, nous détaillerons la première étape qui consiste à ajouter l’évènement PropertyChanged au type. Soit la méthode WeaveEvent :


private FieldReference WeaveEvent(TypeDefinition type)
{
    TypeReference eventHandlerTypeRef = GetReference();
    MethodReference combineMethodRef = this.assembly.MainModule.Import(combineMethodBase);
    MethodReference removeMethodRef = this.assembly.MainModule.Import(removeMethodBase);
    const string eventName = "PropertyChanged";

    FieldDefinition eventField = new FieldDefinition("PropertyChanged",
                                                     eventHandlerTypeRef,
                                                     FieldAttributes.Private);
    type.Fields.Add(eventField);

    EventDefinition eventDefinition = new EventDefinition(eventName,
                                                          eventHandlerTypeRef,
                                                          0);

    eventDefinition.AddMethod = CreateEventMethod(string.Format("add_{0}", eventName),
                                                  combineMethodRef,
                                                  eventField);

    eventDefinition.RemoveMethod = CreateEventMethod(string.Format("remove_{0}", eventName),
                                                     removeMethodRef,
                                                     eventField);

    type.Methods.Add(eventDefinition.AddMethod);
    type.Methods.Add(eventDefinition.RemoveMethod);
    type.Events.Add(eventDefinition);

    return eventField;
}

Le layout n’est pas terrible, j’espère que vous ne m’en tiendrez pas rigueur.

Petit rappel : Lorsqu’on est au niveau CIL, on a une bonne visibilité sur ce qu’un langage de plus haut niveau comme C# peut nous cacher. Les évènements constituent un bon exemple. En C#, la déclaration d’un event est simple :


public event PropertyChangedEventHandler PropertyChanged;

Au niveau IL, le compilateur C# va en fait générer un champ privé encapsulé par une propriété un peu spéciale de type event qui possède les méthodes “add” et “remove“. Note : même si ce n’est pas souvent utilisé, sachez qu’à partir de C# il est possible de faire apparaitre ces méthodes pour éventuellement intercepter les abonnements / désabonnements à l’évènement.

Pour ajouter l’évènement PropertyChanged à notre type, nous avons donc :

Ajouté un champ d’instance privé de type NotifyPropertyChangedEventHandler
Ajouté l’évènement (pseudo propriété), qui utilise deux méthodes : add_PropertyChanged et remove_PropertyChanged
Créé les deux méthodes précédentes, qui utilisent respectivement les méthodes statiques Delegate.Combine et Delegate.Remove pour ajouter et supprimer les handlers au champ d’instance

Puisque l’IL n’est pas très lisible, voici la traduction C# de ces deux méthodes :


public void add_PropertyChanged(PropertyChangedEventHandler value)
{
    this.PropertyChanged =
		(PropertyChangedEventHandler) Delegate.Combine(this.PropertyChanged, value);
}

public void remove_PropertyChanged(PropertyChangedEventHandler value)
{
    this.PropertyChanged =
		(PropertyChangedEventHandler) Delegate.Remove(this.PropertyChanged, value);
}

Dans notre exemple précédent, on délègue la création de ces deux méthodes à CreateEventMethod dont voici la définition :


private MethodDefinition CreateEventMethod(string methodName,
                                           MethodReference delegateMethodReference,
                                           FieldReference eventField)
{
    const MethodAttributes attributes = MethodAttributes.Public |
                                        MethodAttributes.HideBySig |
                                        MethodAttributes.Final |
                                        MethodAttributes.SpecialName |
                                        MethodAttributes.NewSlot |
                                        MethodAttributes.Virtual;

    TypeReference eventHandlerTypeRef = GetReference();
    TypeReference voidType = GetReference(typeof (void));

    MethodDefinition methodDef = new MethodDefinition(methodName, attributes, voidType);

    methodDef.Parameters.Add(new ParameterDefinition(eventHandlerTypeRef));
    CilWorker cilWorker = methodDef.Body.CilWorker;
    cilWorker.Emit(OpCodes.Ldarg_0);
    cilWorker.Emit(OpCodes.Ldarg_0);
    cilWorker.Emit(OpCodes.Ldfld, eventField);
    cilWorker.Emit(OpCodes.Ldarg_1);
    cilWorker.Emit(OpCodes.Call, delegateMethodReference);
    cilWorker.Emit(OpCodes.Castclass, eventHandlerTypeRef);
    cilWorker.Emit(OpCodes.Stfld, eventField);
    cilWorker.Emit(OpCodes.Ret);
    return methodDef;
}

Notez l’API intuitive que propose Cecil pour ce genre de choses : on instancie une définition de l’élément que l’on cherche à ajouter au type (FieldDefinition, EventDefinition, MethodDefinition, etc.), on la configure si besoin, et on l’ajoute à la définition parente. Pour ce qui est de l’émission d’IL pour le corps des méthodes, il suffit d’obtenir un CilWorker et de créer séquentiellement les instructions en utilisant les codes d’opérations du langage intermédiaire.

Voilà pour la création de l’évènement PropertyChanged. Notre type est à présent une implémentation valide de l’interface INotifyPropertyChanged, puisque qu’il respecte le contrat imposé par cette dernière : exposer un évènement PropertyChanged, de type PropertyChangedEventHandler. (Etape [#1] du schéma)

Il ne reste plus qu’à déclencher cet évènement, et pour cela, il est habituellement préférable de prévoir une méthode spécifique qui sera appellée à partir des setters (Etape [#2]). Nous l’appellons ici FireNotifyPropertyChanged et c’est la méthode WeaveEventFiringHelper de notre transformer qui se charge de l’ajouter au type instrumenté :


private MethodReference WeaveEventFiringHelper(FieldReference eventField, TypeDefinition type)
{
    MethodReference invokeMethodRef = this.assembly.MainModule.Import(invokeMethodBase);
    MethodReference argsCtorMethodRef = this.assembly.MainModule.Import(constructorMethodBase);
    TypeReference stringTypeRef = GetReference();
    TypeReference voidTypeRef = GetReference(typeof (void));

    MethodDefinition firePropertyChanged =
        new MethodDefinition("FirePropertyChanged", MethodAttributes.Private, type);
    firePropertyChanged.ReturnType = new MethodReturnType(voidTypeRef);
    ParameterDefinition propertyNameParameter =
        new ParameterDefinition("propertyName", 0, ParameterAttributes.None, stringTypeRef);
    firePropertyChanged.Parameters.Add(propertyNameParameter);

    CilWorker cilWorker = firePropertyChanged.Body.CilWorker;

    Instruction returnInstruction = cilWorker.Create(OpCodes.Ret);
    cilWorker.Emit(OpCodes.Ldarg_0);
    cilWorker.Emit(OpCodes.Ldfld, eventField);
    cilWorker.Emit(OpCodes.Brfalse_S, returnInstruction);
    cilWorker.Emit(OpCodes.Ldarg_0);
    cilWorker.Emit(OpCodes.Ldfld, eventField);
    cilWorker.Emit(OpCodes.Ldarg_0);
    cilWorker.Emit(OpCodes.Ldarg_1);
    cilWorker.Emit(OpCodes.Newobj, argsCtorMethodRef);
    cilWorker.Emit(OpCodes.Callvirt, invokeMethodRef);
    cilWorker.Append(returnInstruction);
    type.Methods.Add(firePropertyChanged);

    return firePropertyChanged;
}

La FieldReference récupérée en argument est celle retournée par la méthode précédente, WeaveEvent, qui a ajouté l’évènement au type. Elle représente d’ailleurs le champ de l’évènement, qui doit être utilisé pour l’invocation. La traduction C# de la méthode générée dynamiquement correspond à :


    private void FirePropertyChanged(string propertyName)
    {
        if (this.PropertyChanged != null)
        {
            this.PropertyChanged.Invoke(this, new PropertyChangedEventArgs(propertyName));
        }
    }

C’est complètement équivalent au code de l’étape [#2] dans le premier schéma.

Instrumentation des setters

A ce stade, pour résumer, nous avons :

[#1] Implémenté INotifyPropertyChanged en ajoutant un évènement PropertyChanged au type
[#2] Créé une méthode “helper” pour déclencher l’évènement

Très logiquement, il ne reste plus qu’à appeller cette dernière à partir de tous les setters des propriétés du type que l’on modifie (étape [#3]). Cette fois-ci, on ne va pas créer un nouveau champ, un nouvel évènement ou une nouvelle méthode, on va modifier le code CIL du corps de méthodes existantes. Car un setter de propriété est une méthode traditionnelle.

Examinons la méthode WeaveEventTriggers du transformer, qui est responsable de cette tache :


private static void WeaveEventTriggers(TypeDefinition type, MethodReference firePropertyChanged)
{
    foreach (PropertyDefinition property in type.Properties)
    {
        MethodDefinition method = property.SetMethod;
        if (method == null)
        {
            continue;
        }

        Instruction retInstruction = method.Body.Instructions[method.Body.Instructions.Count - 1];

        CilWorker cilWorker = method.Body.CilWorker;
        cilWorker.InsertBefore(retInstruction, cilWorker.Create(OpCodes.Ldarg_0));
        cilWorker.InsertBefore(retInstruction, cilWorker.Create(OpCodes.Ldstr, property.Name));
        cilWorker.InsertBefore(retInstruction, cilWorker.Create(OpCodes.Call, firePropertyChanged));
    }
}

Encore une fois, l’implémentation est naïve et nous verrons s’il est possible de l’améliorer plus tard. La logique est simple :

On itère sur toutes les propriétés du type. (Pas très malin…)
On récupère la définition de la méthode du setter.
On récupère une référence vers la dernière instruction du corps du setter
On injecte le code CIL correspondant à l’appel de la méthode FirePropertyChanged avant la dernière instruction pour que la notification soit lançée à la fin de chaque modification.

En gros, si le setter en C# est du genre :


	public void set_Name(string value)
	{
		this.name = value;
	}

On le transforme en :


	public void set_Name(string value)
	{
		this.name = value;
		FirePropertyChanged("Name");
	}

Note : combineMethodBase, invokeMethodBase, constructorMethodBase et removeMethodBase, référencés dans les méthodes du Transformer, sont des membres statiques initialisés de la façon suivante :


private static readonly MethodBase combineMethodBase;
private static readonly MethodBase invokeMethodBase;
private static readonly MethodBase constructorMethodBase;
private static readonly MethodBase removeMethodBase;

static Transformer()
{
    var type = typeof (Delegate);
    combineMethodBase = type.GetMethod("Combine", new[] {type, type});
    removeMethodBase = type.GetMethod("Remove");
    type = typeof (PropertyChangedEventHandler);
    invokeMethodBase = type.GetMethod("Invoke");
    type = typeof (PropertyChangedEventArgs);
    constructorMethodBase = type.GetConstructor(new[] {typeof (string)});
}

Les MethodBase sont des types de l’API d’introspection de System.Reflection. Il est facile de récupérer les MethodReference correspondantes (API Cecil) en utilisant la méthode Import d’une ModuleDefinition.

Conclusion intermédiaire

Voilà une première version du “transformer” capable d’instrumenter un assembly existant pour faire implémenter INotifyPropertyChanged à certains de ses types automatiquement. Les améliorations possibles sont nombreuses, et je ne vais en citer que quelques unes :

Meilleure utilisation de Cecil : après tout, je découvre et suis donc loin d’être un expert
Meilleure intégration au process de build, en utilisant une custom task MSBuild par exemple
Version complète de l’instrumentation : l’évènement PropertyChanged ne doit être déclenché que lorsque la valeur affectée à la propriété est différente
Gestion des exceptions et du logging (évidemment)
Etc.

Cecil est un outil extrêmement puissant et facile d’utilisation. Pour info, la mise en place de cette version du Transformer n’a pas dû me prendre 2 heures, alors que ~~la femme de ma vie me parlait~~ je faisais autre chose en même temps, et que je découvrais complètement l’API non documentée. Il est préférable par contre de connaître le CIL, même si ILdasm ou Reflector peuvent vous assister efficacement. Enfin, et presque paradoxalement, la prise en main de Cecil vous paraitra déroutante si vous avez l’habitude d’utiliser System.Reflection et System.Reflection.Emit.

Au final ma première expérience est définitivement positive, et je n’hésiterai pas dans le futur à recourir à Cecil au besoin. Je pense d’ailleurs qu’en collaboration avec une couche facilitant son utilisation dans un context post-build, on aurait quelque chose d’assez terrible, probablement plus simple à utiliser que PostSharp.Core par exemple pour des tâches bien spécifiques.

Notez tout de même que l’exemple d’utilisation de Cecil présenté ici est un peu tordu, et qu’il y a bien d’autres (meilleurs) moyens d’exploiter ses capacités.

Posted in Articles Tagged: .NET, AOP, C#, Cecil, CIL

ALT.NET en France : Mono à Paris pour la 7ème rencontre

Romain Verdier — Wed, 05 Nov 2008 23:19:51 +0000

Mardi dernier a eu lieu la réunion ALT.NET parisienne du mois de novembre. Généralement, on s’arrange pour que cela tombe le premier mercredi de chaque mois mais cette fois ci nous avons préféré supporter une exception pour bénéficier de la présence de Jean-Baptiste Evain, de passage à Paris. Ce dernier travaille à plein temps pour Novell, en tant que contributeur sur le projet Mono. Oui, vous avez le droit d’être jaloux, en comptant le QA ils doivent être une trentaine. Dans le monde.

Pour la première fois – c’est à noter également – la réunion à été sponsorisée. Cela nous a permis de rassembler la vingtaine de participants dans une jolie salle de meeting gracieusement mise à disposition par Valtech, pour discuter de Mono en mangeant des pizzas. En fait, cette foule a commencé à se rassembler vers 19h dans un bar, avant de migrer chez Valtech à 20h pour la “présentation interactive” de Mono par Jb. Comprendre : 4 slides, lolcatz inclu. Nous avons appris pas mal de choses sur Mono. En vrac, comme toujours : vision et motivations des contributeurs du projet, vision et motivation de Novell, origines de Mono, Novell & Microsoft, les utilisateurs de Mono, Moonlight, Mono.Cecil, Mono Linker, Compiler as a Service, le JIT de Mono et SIMD, l’ouverture de Microsoft, MonoDevelop, le debugger Mono, ASP.NET MVC et Mono, le futur de Mono, Mono et les Picaros, etc.

Nous avons épuisé notre stock de questions Mono vers 22h je pense, et sommes restés sur place un moment pour discuter de diverses choses. Pour ma part, ce fût principalement C# et les nouveautés du langage annoncées à la PDC. Malheureusement, je n’ai pas eu l’occasion de parler à tout le monde, et j’imagine que les sujets furent plus variés que ça. J’ai entendu “F#”, “MVC”, “j’ai soif”, etc.

Finalement, la soirée s’est terminée au Comptoir de l’Arc, où elle avait commencée, mais une fois de plus nous n’avons pu discuter qu’en petits groupes. Dans ceux auxquels je me suis intégré, il était question d’AOP, de Cecil, de PostSharp, de DynamicProxy, de SRE, de CIL, de l’API de profiling native ou de TypeMock. Nous avons également abordé le sujet des grosses solutions Microsoft, de leur pertinence et de leur avenir probable : TFS, Rosario, BizTalk, Entity Framework, Astoria, Azure, etc. Il était intéressant de constater que nous avions tous à peu près pris le temps de visionner les mêmes vidéos de la PDC :

En résumé, l’organisation était différente : nous avions une salle dédiée, nous étions plus nombreux et il y avait un thème. J’ai trouvé ça assez sympa, même s’il va falloir que je m’habitue à la frustration de ne pas pouvoir échanger avec tout le monde.

Et ici vous vous dites, c’est cool, mais des comptes-rendu de ce genre, ça sert à rien. Et moi de répondre : c’est pas faux, mais c’est pas terminé non plus.

Il m’a semblé qu’un point important avait été soulevé durant la discussion au sujet de Mono.

Lorsqu’on comprend un peu mieux ce qu’est le projet, qu’on commence à en apercevoir les contours, certaines interrogations plus précises peuvent survenir. On peut, par exemple, chercher à comprendre ce qui a pu pousser quelques pionniers de l’open source et du monde libre à lancer cette initiative pour le moins ambitieuse. On veut savoir s’il s’agit d’un ~~simple~~ délire de geek, ou d’autre chose. Apparemment, et au risque de vous surprendre, il s’agirait bien d’autre chose. Si vous me permettez de résumer très grossièrement la raison qui semble être la principale motivation des contributeurs du projet Mono : la plateforme .NET a des qualités, il serait bien de pouvoir en profiter sous Linux.

Cependant, même si on trouve le postulat de base légitime, on est en droit de s’interroger sur la faisabilité, le devenir de Mono, la pertinence de l’effort, etc. Et c’est où je veux en venir. La question qui revient souvent (elle est revenue mardi soir) est la suivante :

Ouais, mais vous ne pensez pas, quand même, que c’est un peu dommage d’être à la traine derrière Microsoft ? De travailler comme des bourrins pour coller avec un train de retard à une partie des fonctionnalités de l’implémentation officielle ? Et par dessus tout, vous ne trouvez pas déprimant de ne pas pouvoir innover ou décider de la direction à suivre ?

Bon, OK, il y a plusieurs questions et je me les ai suis posées. M. Evain a assez bien répondu selon moi. En tout cas, suffisamment pour que j’aie l’impression aujourd’hui de percevoir le projet différemment. D’où ma volonté d’insister dans ce billet : L’innovation, ce n’est pas simplement écrire les spécifications de C# 5.0. Décider, ça ne passe pas forcément par la définition de C# 5.0, ou l’architecture de WCF.

Il y a beaucoup d’autres moyens d’innover et de décider. D’une part, le fait de proposer une implémentation de .NET sur un environnement complètement différent, où les contraintes sont autres, ça offre un bon lot d’occasions et de challenges. Par exemple : développer le premier compilateur C# en code managé ou écrire un JIT dont les optimisations rendent envisageable l’utilisation de .NET dans des domaines qui semblaient auparavant inaccessibles. N’importe quel geek peut trouver ça suffisant pour étouffer l’éventuelle frustration dont nous parlions plus tôt. D’autre part, au delà de la course à l’implémentation, le projet Mono permet à de nombreux outils et librairies n’existant pas sous Windows, par exemple, de voir le jour, et d’être utilisés par la communauté toute entière. Au hasard : Cecil. C’est également un vecteur d’innovation.

Accessoirement, je suis curieux de savoir ce que vous avez pensé de la réunion. J’ai vu que certains prenaient des notes donc je garde un oeil sur google reader, mais comme d’hab, au cas où vous en doutiez, sachez que vos commentaires ici sont appréciés.

Posted in Posts Tagged: .NET, ALT.NET, Mono