C# paramètres facultatifs sur les méthodes de remplacement

Une chose à noter ici est que la version de remplacement est appelée à chaque fois. Modifier le remplacement:

public override void MyMethod(string s = "bbb")
{
  Console.Write("derived: ");
  base.MyMethod(s);
}

Et la sortie est:

derived: bbb
derived: aaa

Une méthode dans une classe peut faire un ou deux des éléments suivants:

1. Il définit une interface pour un autre code pour appeler.
2. Il définit une mise en œuvre pour exécuter lors de l'appel.

Il ne peut pas faire les deux, comme une méthode abstraite ne s'occupe que de l'ancien.

Dans BBB l'appel MyMethod() appelle une méthode défini dans AAA.

Car il y a une substitution dans BBB, en appelant cette méthode aboutit à une mise en œuvre dans BBB appelé.

Maintenant, la définition de l' AAA informe le code appelant, de deux choses l'une (enfin, quelques autres encore qui n'ont pas d'importance ici).

1. La signature void MyMethod(string).
2. (Pour les langues qui le prennent en charge) la valeur par défaut du paramètre unique est "aaa" et, par conséquent, lors de la compilation d'un code de la forme MyMethod() si aucune méthode d'appariement MyMethod() peut être trouvé, vous pouvez le remplacer par un appel à " MyMethod("aaa").

Donc, c'est ce que l'appel en BBB n': Le compilateur voit un appel à MyMethod(), ne trouve pas une méthode MyMethod() mais n'trouver une méthode MyMethod(string). Il voit aussi qu'à l'endroit où il a été défini il y a une valeur par défaut de "aaa", donc au moment de la compilation, ça change de ce à un appel à MyMethod("aaa").

De l'intérieur BBB, AAA est considéré comme le lieu où AAA's méthodes sont définies, même si substituée dans BBB, de sorte qu'ils peut être ignoré.

Au moment de l'exécution, MyMethod(string) est appelée avec l'argument "aaa". Parce qu'il n'y est substituée à la forme, qui est la forme dite, mais il n'est pas appelé à "bbb", parce que la valeur n'a rien à voir avec le moment de l'exécution de la mise en œuvre, mais avec le moment de la compilation définition.

Ajoutant this. les changements de définition qui est examiné, et donc les changements que argument est utilisé dans l'appel.

Edit: Pourquoi ce qui semble le plus intuitif pour moi.

Personnellement, et depuis que je suis à parler de ce qui est intuitif, il ne peut être personnel, je trouve cela plus intuitive pour la raison suivante:

Si j'étais codage BBB alors de savoir si l'appelant ou de la transgression de MyMethod(string), je pense, en tant que "faire AAA truc", c'est BBBs prendre à "faire AAA trucs", mais elle fait AAA choses tout de même. Par conséquent, si l'appel ou de la transgression, je vais être conscient du fait qu'il a été AAA que défini MyMethod(string).

Si j'étais le code appelant, qui a utilisé BBB, je pense de "l'aide BBB trucs". Je ne pourrais pas être très au courant de ce qui a été défini dans AAA, et j'aurais peut-être penser à cela comme un simple détail de l'implémentation (si je n'ai pas utiliser le AAA interface à proximité).

Le compilateur du comportement correspond à mon intuition, c'est pourquoi lors de la première lecture de la question, il me semblait que les Mono avait un bug. Après réflexion, je ne vois pas comment, soit remplit les comportements spécifiques, mieux que les autres.

Pour que la matière même si, tout en restant à un niveau personnel, je n'avais jamais utiliser les paramètres facultatifs dans l'abstrait, virtuel ou de méthodes de remplacement, et si une substitution de quelqu'un d'autre qui l'a fait, je serais match leur.

Cela ressemble à un bug pour moi. Je crois qu'il est bien spécifié,
et qu'il devrait se comporter de la même manière que si vous appelez la
méthode explicite this préfixe.

J'ai simplifié l'exemple d'utiliser seulement une unique virtuel
méthode, et de montrer à la fois ce qui est appelé et la mise en œuvre
ce que la valeur du paramètre est:

using System;

class Base
{
    public virtual void M(string text = "base-default")
    {
        Console.WriteLine("Base.M: {0}", text);
    }   
}

class Derived : Base
{
    public override void M(string text = "derived-default")
    {
        Console.WriteLine("Derived.M: {0}", text);
    }

    public void RunTests()
    {
        M();      //Prints Derived.M: base-default
        this.M(); //Prints Derived.M: derived-default
        base.M(); //Prints Base.M: base-default
    }
}

class Test
{
    static void Main()
    {
        Derived d = new Derived();
        d.RunTests();
    }
}

De sorte que tous nous avons besoin de s'inquiéter sont les trois appels dans un délai de RunTests.
Les choses importantes de la spec pour les deux premiers appels sont section
7.5.1.1, qui parle de la liste des paramètres à être utilisé lors de la recherche des paramètres correspondants:

Pour les méthodes virtuelles et des indexeurs définies dans les classes, le paramètre
la liste est choisi à partir de la plus spécifique de la déclaration ou de la remplacer
de la fonction membre, en commençant par le type statique de l'
récepteur, et à la recherche de ses classes de base.

Et de l'article 7.5.1.2:

Lorsque les arguments sont omis à partir d'une fonction membre correspondant des paramètres facultatifs, la valeur par défaut des arguments de la fonction de déclaration d'un membre sont implicitement passé.

Le "correspondant paramètre optionnel" est le bit qui lie 7.5.2 pour 7.5.1.1.

Pour les deux M() et this.M(), ce paramètre liste devrait être
l'un dans Derived comme type statique du receveur est Derived,
En effet, vous pouvez dire que le compilateur traite
que la liste des paramètres plus tôt dans la compilation, comme si vous
rendre le paramètre obligatoire dans Derived.M(), les deux de l'
les appels de l'échec de sorte que le M() appel nécessite le paramètre d'avoir
une valeur par défaut dans Derived, mais alors l'ignore!

En effet, il y a pire: si vous fournissez une valeur par défaut pour le
paramètre dans Derived mais le rendre obligatoire dans Base, l'appel
M() finit à l'aide de null que la valeur de l'argument. Si rien d'autre,
Je dirais que prouve qu'il s'agit d'un bug: que null valeur ne peut pas venir
à partir de n'importe où valide. (C'est null en raison de celle qui est la valeur par défaut
la valeur de la string type; il est toujours juste utilise la valeur par défaut
pour le type de paramètre.)

Section 7.6.8 de la spécification traite avec la base.M(), qui dit que
ainsi que la non-virtuel le comportement, l'expression est considérée comme
comme ((Base) this).M(); il est donc tout à fait correct pour la méthode de base
à être utilisés pour déterminer l'efficacité de la liste des paramètres. Cela signifie que
la dernière ligne est correcte.

Juste pour rendre les choses plus facile pour ceux qui veulent voir le très étrange bogue décrit ci-dessus, lorsqu'une valeur n'est spécifié nulle part est utilisée:

using System;

class Base
{
    public virtual void M(int x)
    {
        //This isn't called
    }   
}

class Derived : Base
{
    public override void M(int x = 5)
    {
        Console.WriteLine("Derived.M: {0}", x);
    }

    public void RunTests()
    {
        M();      //Prints Derived.M: 0
    }

    static void Main()
    {
        new Derived().RunTests();
    }
}

Le comportement est certainement très étrange; il n'est pas clair pour moi si il est en fait un bug du compilateur, mais il pourrait être.

Le campus a obtenu une bonne quantité de neige la nuit dernière et Seattle n'est pas très bonne sur la façon de traiter avec de la neige. Mon bus n'est pas exécuté ce matin, donc je ne vais pas être en mesure d'entrer dans le bureau de comparer ce que le C# 4 C# 5 et Roslyn dire à propos de ce cas et si ils sont en désaccord. Je vais essayer de poster une analyse plus tard cette semaine, une fois que je suis de retour dans le bureau et peut utiliser les bons outils de débogage.

Je pense que c'est parce que ces valeurs par défaut sont fixés au moment de la compilation. Si vous utilisez un réflecteur, vous verrez la suite pour MyMethod2 à BBB.

public override void MyMethod2()
{
    this.MyMethod("aaa");
}

De Toute Façon, Il A Besoin D'Un Correctif

Je n'hésiterais pas à le considérer comme un bug, soit parce que le résultat est mauvais ou si les résultats sont alors le compilateur ne doit pas vous permettre de le déclarer comme "remplacer, ou au moins de donner un avertissement.

Je vous recommande de le signaler à Microsoft.Connectez

Mais Est-Il Bon Ou Mauvais?

Toutefois quant à savoir si c'est le comportement attendu ou non, laissez-nous d'abord analyser les deux points de vue sur elle.

considérons que nous avons le code suivant:

void myfunc(int optional = 5){ /* Some code here*/ } //Function implementation
myfunc(); //Call using the default arguments

Il y a deux façons de la mettre en œuvre:

1. Que les arguments optionnels sont traités comme des fonctions surchargées, entraînant la suivante:

   void myfunc(int optional){ /* Some code here*/ } //Function implementation
   void myfunc(){ myfunc(5); } //Default arguments implementation
   myfunc(); //Call using the default arguments

2. Que la valeur par défaut est incorporé dans l'appelant, ce qui entraîne dans le code suivant:

   void myfunc(int optional){ /* Some code here*/ } //Function implementation
   myfunc(5); //Call and embed default arguments

Il existe de nombreuses différences entre les deux approches, mais nous allons d'abord prendre un coup d'oeil sur la façon dont l' .Net framework interprète.

1. Dans .Net, vous pouvez remplacer que la méthode avec une méthode qui contient le même nombre d'arguments, mais vous ne pouvez pas remplacer avec une méthode contenant plus arguments, même s'ils sont tous optionnels (ce qui aurait pour résultat un appel haveing la même signature que la méthode de remplacement), disons par exemple que vous avez:

   class bassClass{ public virtual void someMethod()}
   class subClass :bassClass{ public override void someMethod()} //Legal
   //The following is illegal, although it would be called as someMethod();
   //class subClass:bassClass{ public override void someMethod(int optional = 5)} 

2. Vous pouvez surcharger une méthode avec des arguments par défaut avec une autre méthode sans argument, (ce qui a des conséquences désastreuses que je vais discuter dans un des moments), de sorte que le folloing code juridique:

   void myfunc(int optional = 5){ /* Some code here*/ } //Function with default
   void myfunc(){ /* Some code here*/ } //No arguments
   myfunc(); //Call which one?, the one with no arguments!

3. lors de l'utilisation de la réflexion, on doit toujours fournir une valeur par défaut.

Qui sont toutes assez pour prouver que .Net a pris la deuxième mise en œuvre, de sorte que le comportement que l'OP a vu, c'est le droit, au moins selon .Net.

Des problèmes Avec le .Net Approche

Cependant, il existe de réels problèmes avec l' .Net approche.

1. Cohérence

   • Comme dans le cas des OP problème lors de la substitution de la valeur par défaut dans une méthode héritée, alors les résultats peuvent être imprévisibles

   • Lorsque l'origine de l'implantation de la valeur par défaut est modifiée, et depuis que les appelants n'ont pas à se recompilé, nous pourrions nous retrouver avec des valeurs par défaut qui ne sont plus valides

   • Réflexion vous demande de fournir la valeur par défaut, l'appelant n'a pas à savoir

2. Casser le code

   • Lorsque nous avons une fonction avec des arguments par défaut et la dernière, nous avons ajouter une fonction sans arguments, tous les appels maintenant route vers la nouvelle fonction, brisant ainsi tout le code existant, sans notification ou avertissement!

   • Similaire va se passer, si on enlève la fonction sans arguments, tous les appels seront automatiquement l'itinéraire de la fonction avec les arguments par défaut, sans notification ou avertissement! bien que cela pourrait ne pas être l'intention du programmeur

   • En outre, il n'a pas à être régulière méthode d'instance, une méthode d'extension fera le même problème, depuis une extension de la méthode sans paramètres auront préséance sur une méthode d'instance avec les paramètres par défaut!

Résumé: éloignez-vous des ARGUMENTS OPTIONNELS, ET UTILISER à la PLACE des SURCHARGES (COMME L' .NET FRAMEWORK LUI-MÊME NE)