Discussion :

[Troopers]

Bonjour,

J'ai besoin de votre aide pour savoir si il existe un moyen pour corriger un appel ambigu entre deux méthodes à part en renommant les méthodes.

Soit une classe de base avec la méthode suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
protected void Load(XmlReader xrReader) 
{
       ...
}

et la méthode statique suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public static List<Configurator> Load(List<Plugin> pPlugins)
{
       ...
}

On ajoute une nouvelle méthode statique :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public static List<Configurator> Load()
{
       return Configurator.Load(null);
}

et là, patatra... le compilateur ne sait pas distinguer l'appel de la méthode statique d'où l'erreur :

L'appel est ambigu entre les méthodes ou propriétés suivantes*: 'Configurator.Load(System.Xml.XmlReader)' et 'Configurator.Load(System.Collections.Generic.List<Plugin>)'

Les 2 méthodes serait statiques ou non statiques, je comprendrais. Mais avec une statique et une non statique je vois pas ce qui le gêne!!?

[el_pedro]

Et si tu caste ta données null en (List<Plugin>)null : a tester ???
Sinon, comment se comporte public static List<Configurator> Load(List<Plugin> pPlugins) si la liste de Plugin est vide. Si tu n'a pas de problème, passe simplement un new List<Plugin>() en paramètre.
Qu'il ne fasse pas la différence entre un méthode static et une méthode d'instance est bizarre, mais que ça plante ne m'étonne pas, deux méthodes se différencie par leur nom ou par le nombre et le type de leurs paramètres, en passant null en paramètre, tu n'envoi aucun type définie et donc tu ne cible pas tel ou tel méthode.

[Troopers]

J'avais bien pensé à mettre new List<Plugin>() en paramètre, cela fonctionne dans mon cas. Mais j'ai quand même posté pour avoir une explication.
Sinon, bonne idée pour le cast (List<Plugin>)null cela fonctionne également.
Mais je ne m'explique toujours pas pourquoi le compilateur ne sait pas différencier la méthode statique de l'autre. Je sais bien que le prototype de la méthode est définit par le nom de la méthode et le nombre et type de paramètres mais je pensais quand même qu'il y avait une distinction sur le static

[Sehnsucht]

Bonjour,

Ce qui m'étonnait dans l'histoire c'est que ça n'apprécie pas la chose alors que d'un côté on a une méthode "standard" qui attend donc d'être appelée avec une instance de la classe et que de l'autre on a une méthode statique qui donc, est appelée avec la classe elle-même (même si on peut l'appeler avec une instance de celle-ci également)

J'ai donc reproduit le code dans un projet histoire de voir cela par moi-même (Note, bien que je travaille aussi bien en C# qu'en VB.Net, j'ai plus de facilités à coder rapidement dans ce dernier, le code présenté le sera donc dans ce langage), ce qui me donne:

Code VB.Net :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
Public Class Plugin
 
End Class
 
Public Class ConfiguratorBase
    Protected Sub Load(ByVal xrReader As Xml.XmlReader)
        'TODO: Do something
    End Sub
End Class
 
Public Class Configurator
 
    Public Shared Function Load(ByVal pPlugins As List(Of Plugin)) As List(Of Configurator)
        'Todo Do Something
    End Function
 
    Public Shared Function Load() As List(Of Configurator)
        Return Configurator.Load(Nothing)
    End Function
End Class

Et bizarrement chez moi cela compile parfaitement (si on excepte le warning pour la fonction Load qui ne renvoie rien dans mon code)

Donc soit il faut plus de détails, soit ça vient d'autre chose (ou alors je dis VB.Net ^^)

[el_pedro]

C'est bien un problème de signature. Une méthode n'est pas signé par son domaine d'application (static ou non) donc, deux méthodes avec un même nom et les mêmes paramètres sont en concurrences et donc la compilateur alerte.

Dans ton cas, ça n'est pas un problème de ce type, c'est ton paramètre qui n'était pas typé, et donc, le programme ne savais pas quelle méthode utiliser.

[Sehnsucht]

Je regrette je ne suis pas d'accord,

On a une méthode qui prend aucun paramètre d'un côté et de l'autre on a une méthode éponyme avec un paramètre, les signatures sont bien différentes, il suffit d'en écrire les prototypes "à la C":

• Méthode 1: Load(List<Plugin>);
• Méthode 2: Load(void);

sachant que le type de retour ne fait pas partie de la signature on constate très bien qu'elles sont différentes...

Au passage pour être sûr que ce n'était pas un problème dû à VB.Net (ça m'aurait étonné étant donné qu'ils reposent sur le même Framework mais pourquoi pas) j'ai donc créé un nouveau projet en C# et reproduis la copie du code précédent en C# je n'ai toujours pas un seul problème de compilation, donc je persiste dans ma voie en disant que le souci est ailleurs

Cordialement !

Edit: Je viens de comprendre, j'avais mal interprété cette partie de l'explication initiale

Soit une classe de base avec la méthode suivante :

qui me laissait penser que la première méthode Load (qui prend un XmlReader en paramètre) appartenait à la classe mère de Configurator (que j'avais nommée ConfiguratorBase dans mon exemple).
En effet si je place cette méthode dans la classe Configurator là il y a ambiguité des signatures et le cast à l'appel est obligatoire

[Troopers]

@Sehnsucht
Ton code fonctionne car tu as mis 2 classes Configurator et ConfiguratorBase ( j'ai du mal m'exprimer). Pour moi, je n'ai que la clas Configurator avec les 3 méthodes. Pour toi cela fonctionne car tu appel explicitement la méthode de la classe Configurator

[el_pedro]

L'ambiguïté ne viens pas de :
Méthode 1: Load(List<Plugin>);
Méthode 2: Load(void);

Mais de :
Méthode 1: Load(List<Plugin>);
Méthode 2: Load(XmlReader xrReader);

Donc quand on passe null en paramètre, Load(void); est écartée puisque n'ayant pas de paramètres, reste les deux autres.

[Troopers]

@el_pedro
Ok, je ne savais que l'on pouvait appeler une méthode static depuis une instance d'objet (monObjet.MethodeStatic), perso je passe toujours par la classe (Classe.MethodeStatic). Donc du coup je comprends qu'il y ait une ambiguite même si je trouve le fait de pouvoir appeler une méthode static depuis une instance d'objet (monObjet.MethodeStatic) illogique

[kheironn]

Puisque tu appelles ta méthode d'instance et ta méthode static dans la classe dans laquelle elles sont définies, il est normal qu'elles soit disponibles.

Static, c'est du partage entre toutes les instances aussi ! Si tu déclares un membres static dans une classe objet, toutes les instance auront une référence vers cette valeur static ("shared" en vb (c'est plus parlant comme terme) donc "partagé" en français !!!)

Par contre, une fois instancié, ton objet ne présente pas la méthode static

Le fait de pouvoir appeler du static au sein d'une classe permet l'implémentation du pattern singleton si je ne m'abuse.

[Troopers]

Par contre, une fois instancié, ton objet ne présente pas la méthode static

C'est encore plus illogique alors ! Pourquoi mon objet présenterait une méthode tant qu'il n'est pas instancié et une fois instancié, plus de méthode!!

J'aimerai qu'on me donne un exemple concrès de l'utilité de MonObjet.MethodeStatic et qu'on ne peut pas remplacer par MaClasse.MethodeStatic

[kheironn]

Tu ne peux pas faire MonObjet.MethodeStatic (c'est ce que j'ai dit plus haut, peut-être mal dit ?)...

Mais dans ta classe qui contient des méthodes statics et d'instance, tu peux utiliser les deux ! (pas n'importe comment non plus !)

[el_pedro]

En effet, je pense qu'instancier ou non, la méthode est autant accessible. Ca ne reste qu'un raccourcis pour ne pas avoir à taper maClasse.MaStatic().

Pour le singleton... bah justement non, normalement, un singleton n'est pas static. Tu ne possède qu'une méthode static pour récupérer ton instance unique (ou tes instances uniques), sinon, c'est un objet instanciable.

[el_pedro]

Oula, post simultané. Je parle de l'appel static dans l'instance de la classe. Je viens de voir qu'on ne parlais pas tout à fait de la même chose, je suis d'accord avec kheironn.

[kheironn]

En effet, je pense qu'instancier ou non, la méthode est autant accessible. Ca ne reste qu'un raccourcis pour ne pas avoir à taper maClasse.MaStatic().

Pour le singleton... bah justement non, normalement, un singleton n'est pas static. Tu ne possède qu'une méthode static pour récupérer ton instance unique (ou tes instances uniques), sinon, c'est un objet instanciable.

Bien sûr qu'un singleton n'est pas static, sinon quel serait l'intérêt du pattern ?
Mais je pensais bien à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
public sealed class Singleton
{
    static Singleton instance=null;

    Singleton()
    {
    }

    public static Singleton Instance
    {
        get
        {
            if (instance==null)
            {
                instance = new Singleton();
            }
            return instance;
        }
    }
}

dans ce cas là...

[el_pedro]

Pour le singleton... bah justement non, normalement, un singleton n'est pas static. Tu ne possède qu'une méthode static pour récupérer ton instance unique (ou tes instances uniques), sinon, c'est un objet instanciable.

Ce que tu as, pas static mais avec une instance static.

[kheironn]

Je n'ai pas dit le contraire...

[el_pedro]

... Je viens de voir qu'on ne parlais pas tout à fait de la même chose, je suis d'accord avec kheironn.

Un jour on arrivera à se comprendre du premier coup.

[Troopers]

Ok, effectivement MonObjet.MethodeStatic n'est pas possible.

Donc l'ambiguité existe juste par ce que en interne de la classe, les deux méthodes peuvent être appelées sans distinction possible.
Mais je soutiens que le compilateur devrait être capable de lever l'ambiguité si l'appel est MaClasse.Methode et non directement Methode

Merci pour vos réponses et désolé pour les confusions

[kheironn]

Donc l'ambiguité existe juste par ce que en interne de la classe, les deux méthodes peuvent être appelées sans distinction possible.

Tout à fait ! N'oublie pas de marquer le sujet comme résolu avec le petit bouton qui va bien.

@el_pedro : c'est ce qu'on appelle un dialogue de sourds .