Voil=E0, pour une raison un peu longue =E0 expliquer (s'il le faut
vraiment je le ferai mais ce n'est pas indispensable et c'est un peu un
troll :)) je voudrai pouvoir ajouter du code au niveau IL =E0 la
compilation d'une classe . Je souhaite ne pas intervenir au niveau du
source pour ne pas le "poluer".
En fait j'ai deux pistes pour mon probl=E8me qui m'imposent des
exigences un peu diff=E9rentes :
Piste 1 : cr=E9ation =E0 la vol=E9e de m=E9thodes suppl=E9mentaire pour ma
classe. Les m=E9thodes ainsi cr=E9=E9es doivent =EAtre disponibles dans
l'environnement de d=E9veloppement (typage, compl=E9tion etc...). Je
crois que l'intellisense fonctionne =E0 la fois sur le source et via la
r=E9flection de l'assembly donc c'est peut-=EAtre possible.
Piste 2 : g=E9n=E9rer du code IL =E0 ex=E9cuter =E0 l'invocation de
m=E9thodes existantes dans le source. De l'AOP en quelque sorte.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Patrice
Je ne crois pas que ce genre de précisions soient considérées comme faisant "troll". A mon avis, il est bien souvent souhaitable d'expliquer ce que l'on souhaite faire plutôt que de demander des précisions sur la solutuion actuellement retenue. Cela peut permettre éventuellement à quelqu'un de suggérer une approche totalement différente...
Si c'est avant la compilation, il serait assez simple par exemple de créer un code source via un programme quelconque (soit via CodeDom soit en générant directement le fichier source dans le langage de ton choix)...
Un mécanisme de plugin ou d'héritage qui permettrait d'isoler la partie de code concernée ? (si c'est le problème).
-- Patrice
a écrit dans le message de news:
Bonjour à tous,
Voilà, pour une raison un peu longue à expliquer (s'il le faut vraiment je le ferai mais ce n'est pas indispensable et c'est un peu un troll :)) je voudrai pouvoir ajouter du code au niveau IL à la compilation d'une classe . Je souhaite ne pas intervenir au niveau du source pour ne pas le "poluer".
En fait j'ai deux pistes pour mon problème qui m'imposent des exigences un peu différentes :
Piste 1 : création à la volée de méthodes supplémentaire pour ma classe. Les méthodes ainsi créées doivent être disponibles dans l'environnement de développement (typage, complétion etc...). Je crois que l'intellisense fonctionne à la fois sur le source et via la réflection de l'assembly donc c'est peut-être possible.
Piste 2 : générer du code IL à exécuter à l'invocation de méthodes existantes dans le source. De l'AOP en quelque sorte.
Des idées, des pistes, des tuto ?
D'avance merci.
Je ne crois pas que ce genre de précisions soient considérées comme faisant
"troll". A mon avis, il est bien souvent souhaitable d'expliquer ce que l'on
souhaite faire plutôt que de demander des précisions sur la solutuion
actuellement retenue. Cela peut permettre éventuellement à quelqu'un de
suggérer une approche totalement différente...
Si c'est avant la compilation, il serait assez simple par exemple de créer
un code source via un programme quelconque (soit via CodeDom soit en
générant directement le fichier source dans le langage de ton choix)...
Un mécanisme de plugin ou d'héritage qui permettrait d'isoler la partie de
code concernée ? (si c'est le problème).
--
Patrice
<pongla.public@laposte.net> a écrit dans le message de news:
1148283204.406357.262760@j73g2000cwa.googlegroups.com...
Bonjour à tous,
Voilà, pour une raison un peu longue à expliquer (s'il le faut
vraiment je le ferai mais ce n'est pas indispensable et c'est un peu un
troll :)) je voudrai pouvoir ajouter du code au niveau IL à la
compilation d'une classe . Je souhaite ne pas intervenir au niveau du
source pour ne pas le "poluer".
En fait j'ai deux pistes pour mon problème qui m'imposent des
exigences un peu différentes :
Piste 1 : création à la volée de méthodes supplémentaire pour ma
classe. Les méthodes ainsi créées doivent être disponibles dans
l'environnement de développement (typage, complétion etc...). Je
crois que l'intellisense fonctionne à la fois sur le source et via la
réflection de l'assembly donc c'est peut-être possible.
Piste 2 : générer du code IL à exécuter à l'invocation de
méthodes existantes dans le source. De l'AOP en quelque sorte.
Je ne crois pas que ce genre de précisions soient considérées comme faisant "troll". A mon avis, il est bien souvent souhaitable d'expliquer ce que l'on souhaite faire plutôt que de demander des précisions sur la solutuion actuellement retenue. Cela peut permettre éventuellement à quelqu'un de suggérer une approche totalement différente...
Si c'est avant la compilation, il serait assez simple par exemple de créer un code source via un programme quelconque (soit via CodeDom soit en générant directement le fichier source dans le langage de ton choix)...
Un mécanisme de plugin ou d'héritage qui permettrait d'isoler la partie de code concernée ? (si c'est le problème).
-- Patrice
a écrit dans le message de news:
Bonjour à tous,
Voilà, pour une raison un peu longue à expliquer (s'il le faut vraiment je le ferai mais ce n'est pas indispensable et c'est un peu un troll :)) je voudrai pouvoir ajouter du code au niveau IL à la compilation d'une classe . Je souhaite ne pas intervenir au niveau du source pour ne pas le "poluer".
En fait j'ai deux pistes pour mon problème qui m'imposent des exigences un peu différentes :
Piste 1 : création à la volée de méthodes supplémentaire pour ma classe. Les méthodes ainsi créées doivent être disponibles dans l'environnement de développement (typage, complétion etc...). Je crois que l'intellisense fonctionne à la fois sur le source et via la réflection de l'assembly donc c'est peut-être possible.
Piste 2 : générer du code IL à exécuter à l'invocation de méthodes existantes dans le source. De l'AOP en quelque sorte.
Des idées, des pistes, des tuto ?
D'avance merci.
Pon
Merci pour la réponse.
Je ne crois pas que ce genre de précisions soient considérées comme faisant "troll". A mon avis, il est bien souvent souhaitable ...permettre éventu ellement à quelqu'un de suggérer une approche totalement différente...
Tout à fait d'accord, c'est seulement que le sujet en question fait couler beaucoup d'encre (j'ai testé :). Mais allons-y, je précise : Je dois gérer des références mutuelles entre classes (associations UML navigables dans les deux sens). Ex : C1 a un attribut de type C2 et réciproquement C2 a un argument de type C1 correspondant a la même relation. Evidemment, on veut garantir proprement et à moindre frais la cohérence c'est à dire l'invariant (avec o1 et o2 resp. de type C1 et C2) o1.c2.c1 is o1 (et inversement).
Gérer le problème sur un cas n'est pas très difficile. Ca demande un peu de travail mais avec les setter qui vont bien (et en sous-classant des types collection avec des add, remove, clear spécifiques quand on a des relation 1-n ou n-n) on gère à la mimine les mise à jour réciproques (en évitant que ça boucle). Et avec des visibilités friend sur les setter on arrive assez bien à obtenir qqch de propre et de transparent pour les clients de l'assembly.
Le problème c'est qu'on répète le même pattern autant de fois que nécessaire. Dans mon cas c'est un cinquantaine de classe avec en moyenne 5 références de ce type, ce qui nous fait 250 répétitions du pattern. Un peu pénible. Sans parler d'une éventuelle modification du pattern.
D'où ma volonté de centraliser cette tuyauterie. Je voulais donc marquer ces property particulière (avec référence mutuelle dans la classe typant la property) d'un attribut portant le nom de la property réciproque. J'imaginais ensuite via un mécanisme à définir gérer l'injection à la volée du code correspondant à cette gestion (cet "aspect"). Mais il y pas mal d'option : d'abord où injecter le code ? Ma préférence irait à une injection de code source mais dans une source intermédiaire indépendant du mien je crois que c'est le principe d'AspectJ par exemple si j'ai bien compris). Je peux aussi injecter du code IL dans l'assembly via refelxion.emit ou encore passer par le remoting et les IessageSink. Il y a d'autres options mais elles sont très différentes et j'y reviendrai peut être.
J'espère avoir été clair (pas sûr : )
Merci pour la réponse.
Je ne crois pas que ce genre de précisions soient considérées comme faisant
"troll". A mon avis, il est bien souvent souhaitable ...permettre éventu ellement à quelqu'un de
suggérer une approche totalement différente...
Tout à fait d'accord, c'est seulement que le sujet en question fait
couler beaucoup d'encre (j'ai testé :). Mais allons-y, je précise :
Je dois gérer des références mutuelles entre classes (associations
UML navigables dans les deux sens). Ex : C1 a un attribut de type C2 et
réciproquement C2 a un argument de type C1 correspondant a la même
relation. Evidemment, on veut garantir proprement et à moindre frais
la cohérence c'est à dire l'invariant (avec o1 et o2 resp. de type C1
et C2) o1.c2.c1 is o1 (et inversement).
Gérer le problème sur un cas n'est pas très difficile. Ca demande un
peu de travail mais avec les setter qui vont bien (et en sous-classant
des types collection avec des add, remove, clear spécifiques quand on
a des relation 1-n ou n-n) on gère à la mimine les mise à jour
réciproques (en évitant que ça boucle). Et avec des visibilités
friend sur les setter on arrive assez bien à obtenir qqch de propre et
de transparent pour les clients de l'assembly.
Le problème c'est qu'on répète le même pattern autant de fois que
nécessaire. Dans mon cas c'est un cinquantaine de classe avec en
moyenne 5 références de ce type, ce qui nous fait 250 répétitions
du pattern. Un peu pénible. Sans parler d'une éventuelle modification
du pattern.
D'où ma volonté de centraliser cette tuyauterie. Je voulais donc
marquer ces property particulière (avec référence mutuelle dans la
classe typant la property) d'un attribut portant le nom de la property
réciproque. J'imaginais ensuite via un mécanisme à définir gérer
l'injection à la volée du code correspondant à cette gestion (cet
"aspect").
Mais il y pas mal d'option : d'abord où injecter le code ? Ma
préférence irait à une injection de code source mais dans une source
intermédiaire indépendant du mien je crois que c'est le principe
d'AspectJ par exemple si j'ai bien compris). Je peux aussi injecter du
code IL dans l'assembly via refelxion.emit ou encore passer par le
remoting et les IessageSink.
Il y a d'autres options mais elles sont très différentes et j'y
reviendrai peut être.
Je ne crois pas que ce genre de précisions soient considérées comme faisant "troll". A mon avis, il est bien souvent souhaitable ...permettre éventu ellement à quelqu'un de suggérer une approche totalement différente...
Tout à fait d'accord, c'est seulement que le sujet en question fait couler beaucoup d'encre (j'ai testé :). Mais allons-y, je précise : Je dois gérer des références mutuelles entre classes (associations UML navigables dans les deux sens). Ex : C1 a un attribut de type C2 et réciproquement C2 a un argument de type C1 correspondant a la même relation. Evidemment, on veut garantir proprement et à moindre frais la cohérence c'est à dire l'invariant (avec o1 et o2 resp. de type C1 et C2) o1.c2.c1 is o1 (et inversement).
Gérer le problème sur un cas n'est pas très difficile. Ca demande un peu de travail mais avec les setter qui vont bien (et en sous-classant des types collection avec des add, remove, clear spécifiques quand on a des relation 1-n ou n-n) on gère à la mimine les mise à jour réciproques (en évitant que ça boucle). Et avec des visibilités friend sur les setter on arrive assez bien à obtenir qqch de propre et de transparent pour les clients de l'assembly.
Le problème c'est qu'on répète le même pattern autant de fois que nécessaire. Dans mon cas c'est un cinquantaine de classe avec en moyenne 5 références de ce type, ce qui nous fait 250 répétitions du pattern. Un peu pénible. Sans parler d'une éventuelle modification du pattern.
D'où ma volonté de centraliser cette tuyauterie. Je voulais donc marquer ces property particulière (avec référence mutuelle dans la classe typant la property) d'un attribut portant le nom de la property réciproque. J'imaginais ensuite via un mécanisme à définir gérer l'injection à la volée du code correspondant à cette gestion (cet "aspect"). Mais il y pas mal d'option : d'abord où injecter le code ? Ma préférence irait à une injection de code source mais dans une source intermédiaire indépendant du mien je crois que c'est le principe d'AspectJ par exemple si j'ai bien compris). Je peux aussi injecter du code IL dans l'assembly via refelxion.emit ou encore passer par le remoting et les IessageSink. Il y a d'autres options mais elles sont très différentes et j'y reviendrai peut être.
