CodeDom & abstract override

Bonjour,

Gros soucis à l'utilisation du CodeDom.

Je cherche à déclarer une méthode en abstract override, mais visiblement le provider par défaut ne le gère pas.

Code:

---

1 2 3 4 5 6 7 8 9 10

// set its attributes MemberAttributes attributes = MemberAttributes.Public; // if abstract if(isAbstract) attributes |= MemberAttributes.Abstract; // if override if(isOverride) attributes |= MemberAttributes.Override; // set the computed attributes this._method.Attributes = attributes;

---

abstract + public ca marche bien
override + public ca marche bien,
mais abstract + override non.
Il me fait le public virtual à la place (attributs par défaut)
(et public + abstract + override pareil)

Question :
* Quelqu'un s'est déjà penché sur le problème et a trouvé un moyen de contourner / résoudre ?
* Non, le CodeSnippetExpression n'est pas la solution que j'attends ;)

Merci

Une méthode abstract ne peut pas être un override, ça n'aurait pas de sens... pourquoi voudrais-tu faire ça ?

Si si ça a un sens.

Une classe abstraite peut être dérivée en une autre classe abstraite.
On dit "enrichie".

Dans ce cas, chacune de ses méthodes abstraite doit être soit implémentée, soit "propagée" par le modifieur abstract override.

Je me sers très couramment de ce principe.
Mais ceci n'est pas le sujet de ce post.

Je m'inquiète beaucoup de la limite du CodeDom.

effectivement c'est peut-être un bug de CodeDom... bizarre :?

Mais de toutes façons, je persiste à pense que le modifieur abstract override ne sert à rien :

Citation:

---

Dans ce cas, chacune de ses méthodes abstraite doit être soit implémentée, soit "propagée" par le modifieur abstract override.

---

Si tu ne l'implémentes pas, elle sera quand même propagée aux classes dérivées, sans avoir besoin de ce modifieur... fais le test, tu verras bien

Je te garantie que non ;)
Je t'invite à faire le test.
Ton compilateur va râler parce que tu n'overrides pas un membre abstrait.
C'est un mécanisme que j'utilise vraiment souvent

La règle pour le compilateur est simple : si tu dérives d'une abstraite, tu dois overrider tous les membres abstraits.

Bon, comme tu m'as fait douter, j'ai testé... et je maintiens ma position !

Citation:

---

Envoyé par Mose

La règle pour le compilateur est simple : si tu dérives d'une abstraite, tu dois overrider tous les membres abstraits.

---

A quoi j'ajouterais : sauf si ta classe dérivée est aussi abstraite.

Ce code compile sans problème :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

public abstract class A { public abstract void X(); }   public abstract class B : A { }   public class C : B { public override void X() { Console.WriteLine("Hello world !"); } }

---

Ou alors on a pas le même compilateur... je code en C# 3 (VS2008), peut-être que ça a changé par rapport à la version précédente ? En tous cas ça me semble plus logique comme ça...

Effectivement, ça a changé, je le confirme également.
En 2.0 il fallait impérativement overrider.
C'est pas plus mal qu'ils y aient enfin pensé.
Mais c'est dommage qu'ils aient attendu aussi longtemps ;)

Merci pour ce petit rafraichissement et pour cette preuve.
Désolé d'avoir douté.

Bon... ce qui est dommage c'est qu'il y a quand même cette limitation dans le CodeDom. Du coup ça limite méchamment l'utilisabilité de mon AddIn VS.Net (tout le monde n'ayant pas le framework 3).

Je réitère : quelqu'un a-t-il déjà rencontré le problème et connait une parade ?
Merci...

Citation:

---

Envoyé par Mose

Effectivement, ça a changé, je le confirme également.
En 2.0 il fallait impérativement overrider.

---

Le code fourni par tomlev est tout à fait correct dans toutes les versions de .NET à ma connaissance.

abstract override est utilisé dans le cas type suivant :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

using System; class A { public virtual void F() { Console.WriteLine("A.F"); } } abstract class B: A { public abstract override void F(); } class C: B { public override void F() { Console.WriteLine("C.F"); } }

---

La classe abstraite B force la redéfinition de la méthode F par ses classes héritées, et rend l'implémentation de base inaccessible.

Merci Greybird de cet éclaircissement... en gros si je comprends bien, abstract override permet de rendre abstraite une méthode qui était implémentée dans une classe de base ?

J'avais jamais vu ça avant... on en apprend tous les jours ;)

wow
obliger à redéfinir une sub plus bas qui était pourtant définie plus haut ^^

y manque vraiment plus que le multi-héritage alors ...

Ok, je viens de tester en 2.0 et ca fonctionne.

Je suis sûr que je n'ai pas inventé ce que je raconte, mais je n'ai plus le fx1.1 sur ma machine donc je ne prouverai pas mes dires.

Il n'empêche que c'est con que le CodeDom ne gère pas tous les cas possibles...
Mais du coup c'est moins limitant.