Необов’язкові параметри C # для перевизначених методів

Question 1

Схоже, у .NET Framework виникає проблема з необов’язковими параметрами, коли ви перевизначаєте метод. Вихідні дані коду нижче: "bbb" "aaa". Але результат, який я очікую: "bbb" "bbb". Чи є для цього рішення. Я знаю, що це можна вирішити за допомогою перевантаження методів, але цікаво, чому причина цього. Також код чудово працює в Mono.

class Program
{
    class AAA
    {
        public virtual void MyMethod(string s = "aaa")
        {
            Console.WriteLine(s);
        }

        public virtual void MyMethod2()
        {
            MyMethod();
        }
    }

    class BBB : AAA
    {
        public override void MyMethod(string s = "bbb")
        {
            base.MyMethod(s);
        }

        public override void MyMethod2()
        {
            MyMethod();
        }
    }

    static void Main(string[] args)
    {
        BBB asd = new BBB();
        asd.MyMethod();
        asd.MyMethod2();
    }
}

Question 2

Тут варто зазначити одне, що замінена версія викликається кожного разу. Змініть заміну на:

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

І результат:

derived: bbb
derived: aaa

Метод у класі може зробити одне або два з наступного:

Він визначає інтерфейс для виклику іншого коду.
Він визначає реалізацію, яка буде виконуватися при виклику.

Це може не робити і того, і іншого, оскільки абстрактний метод робить лише перший.

У BBBрамках викликів MyMethod()виклику використовується метод, визначений уAAA .

Оскільки є перевизначення в BBB, виклик цього методу призводить до реалізації у виклику BBB.

Тепер визначення в AAAповідомляє код виклику двох речей (ну, ще декількох, які тут не мають значення).

Підпис void MyMethod(string).
(Для тих мов, які його підтримують) значенням за замовчуванням для одного параметра є, "aaa"і тому при компіляції коду форми, MyMethod()якщо не MyMethod()вдається знайти відповідний метод , ви можете замінити його викликом `MyMethod (" aaa ").

Отже, це те, що BBBробить виклик : Компілятор бачить виклик MyMethod(), не знаходить методу, MyMethod()але знаходить метод MyMethod(string). Він також бачить, що там, де це визначено, є значення за замовчуванням "aaa", тому під час компіляції воно змінює це на виклик MyMethod("aaa").

Зсередини BBB, AAAвважається місцем , де AAAвизначені «S методи, навіть якщо переопределяется в BBB, так що вони можуть бути перевизначені.

Під час виконання MyMethod(string)викликається з аргументом "aaa". Оскільки існує перевизначена форма, ця форма називається, але вона не викликається з "bbb", оскільки це значення не має нічого спільного з реалізацією часу виконання, а з визначенням часу компіляції.

Додавання this.змін, визначення яких перевіряється, і таким чином змінює аргумент, який використовується у виклику.

Редагувати: Чому це здається мені більш інтуїтивним.

Особисто, і оскільки я говорю про те, що є інтуїтивним, воно може бути лише особистим, я вважаю це більш інтуїтивним з наступної причини:

Якби я кодував, BBBто виклик чи перевизначення MyMethod(string), я б вважав це як "робити AAAречі" - це BBBвізьмемо на себе "робити AAAречі", але це робити AAAвсе одно. Отже, дзвінок чи перевизначення, я буду знати про те, що це було AAAвизначено MyMethod(string).

Якби я називав код, який використовував BBB, я б подумав про "використання BBBречей". Можливо, я не дуже обізнаний, що було спочатку визначено в AAA, і, можливо, я вважав би це лише деталлю реалізації (якби я також не використовувавAAA інтерфейс поруч).

Поведінка компілятора відповідає моїй інтуїції, саме тому при першому читанні запитання мені здалося, що у Моно була помилка. Після розгляду я не можу зрозуміти, як той чи інший виконує зазначену поведінку краще за інший.

Однак, залишаючись на особистому рівні, я ніколи не використовував би необов’язкові параметри з абстрактними, віртуальними або перевизначеними методами, і, якщо перевизначував чужі, це робило, я б збігався з їхніми.

Question 3

Ви можете визначити неоднозначність, зателефонувавши:

this.MyMethod();

(в MyMethod2())

Будь то помилка - це складно; все ж це виглядає непослідовно. Resharper попереджає, що ви просто не повинні змінювати значення за замовчуванням у заміну, якщо це допомагає; p Звичайно, resharper також повідомляє вамthis. надлишковий, і пропонує видалити його для вас ... що змінює поведінку - тому resharper також не є ідеальним.

Здається, це може кваліфікуватися як помилка компілятора, я вас додам. Мені потрібно було б подивитися дуже уважно, щоб бути впевненим ... де Ерік, коли він тобі потрібен, так?

Редагувати:

Ключовим моментом тут є мовна специфікація; давайте розглянемо §7.5.3:

Наприклад, набір кандидатів для виклику методу не включає методи, позначені перевизначенням (§7.4), а методи базового класу не є кандидатами, якщо застосовується будь-який метод у похідному класі (§7.6.5.1).

(і справді § 7.4 чітко опускає overrideметоди з розгляду)

Тут є певний конфлікт .... він стверджує, що базові методи не використовуються, якщо в похідному класі є застосовний метод, - що призведе нас до похідного методу, але в той же час він говорить, що позначені методи overrideне є розглядається.

Але, §7.5.1.1 тоді стверджує:

Для віртуальних методів та індексаторів, визначених у класах, список параметрів вибирається з найбільш конкретного оголошення або перевизначення елемента функції, починаючи зі статичного типу одержувача та шукаючи його базові класи.

а потім §7.5.1.2 пояснює, як оцінюються значення під час виклику:

Під час обробки часу виклику члена функції (§7.5.4) вирази або посилання на змінні списку аргументів обчислюються в порядку, зліва направо, наступним чином:

... (відрізати) ...

Коли аргументи опущені з елемента функції з відповідними необов’язковими параметрами, аргументи за замовчуванням декларації члена функції неявно передаються. Оскільки вони завжди постійні, їх оцінка не вплине на порядок оцінки решти аргументів.

Це явно підкреслює, що він розглядає список аргументів, який раніше був визначений у §7.5.1.1 як такий, що походить із найбільш конкретної декларації або заміни . Здається розумним, що це «декларація методу», про яку йдеться у п. 7.5.5.2, отже передане значення повинно бути від найбільш похідного аж до статичного типу.

Це може припустити: csc має помилку, і вона повинна використовувати похідну версію ("bbb bbb"), якщо вона не обмежена (через base.або перекидання до базового типу) для перегляду оголошень базового методу (§7.6.8 ).

Question 4

Це здається мені помилкою. Я вважаю , що це добре визначений, і що він повинен вести себе таким же чином , як і при виклику методу з явним thisпрефіксом.

Я спростив приклад, використовуючи лише один віртуальний метод, і показую, яка саме реалізація викликається, і яке значення параметра:

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();
    }
}

Отже, все, про що нам потрібно турбуватися, це три дзвінки в RunTests. Важливими бітами специфікації для перших двох викликів є розділ 7.5.1.1, який розповідає про список параметрів, який буде використовуватися при пошуку відповідних параметрів:

Для віртуальних методів та індексаторів, визначених у класах, список параметрів вибирається з найбільш конкретного оголошення або перевизначення елемента функції, починаючи зі статичного типу одержувача та шукаючи його базові класи.

І розділ 7.5.1.2:

Коли аргументи опущені з елемента функції з відповідними необов’язковими параметрами, аргументи за замовчуванням декларації члена функції неявно передаються.

"Відповідний необов'язковий параметр" - це біт, який зв'язує 7.5.2 - 7.5.1.1.

Для обох M()і this.M(), що список параметрів повинен бути один в Derivedякості статичного типу приймача Derived, В насправді, ви можете сказати , що компілятор трактує , що в список параметрів раніше в компіляції, так як якщо ви зробите параметр обов'язковий після прибуття Derived.M(), як в виклики не вдаються - тому для M()виклику потрібно, щоб параметр мав значення за замовчуванням Derived, але потім ігнорує його!

Дійсно, це погіршується: якщо ви вказали значення за замовчуванням для параметра в, Derivedале зробите його обов’язковим для Base, виклик M()закінчується використанням nullяк значення аргументу. Якщо нічого іншого, я б сказав, що це доводить, що це помилка: це nullзначення не може надходити з будь-якого місця. (Це nullобумовлено тим, що це значення за замовчуванням для stringтипу; воно завжди просто використовує значення за замовчуванням для типу параметра.)

Розділ 7.6.8 специфікації стосується base.M (), де сказано, що, як і невіртуальна поведінка, вираз розглядається як ((Base) this).M(); тому цілком правильно, щоб базовий метод використовувався для визначення ефективного списку параметрів. Це означає, що остаточний рядок правильний.

Просто для того, щоб полегшити ситуацію кожному, хто хоче побачити справді дивну помилку, описану вище, де використовується значення, не вказане ніде:

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();
    }
}

Question 5

Ти намагався:

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

Отже, ви фактично говорите своїй програмі використовувати перевизначений метод.

Question 6

Поведінка, безумовно, дуже дивна; мені незрозуміло, чи насправді це помилка компілятора, але це може бути.

Вчора ввечері в кампусі випало досить багато снігу, і Сіетл не дуже добре справляється зі снігом. Мій автобус не їде сьогодні вранці, тому я не зможу зайти в офіс, щоб порівняти, що кажуть C # 4, C # 5 та Roslyn щодо цієї справи, і якщо вони не згодні. Я спробую опублікувати аналіз пізніше цього тижня, коли я повернусь в офіс і зможу використовувати належні інструменти налагодження.

Question 7

Можливо, це пов’язано з неоднозначністю, а компілятор надає пріоритет базовому / суперкласу. Наведена нижче зміна коду вашого класу BBB з додаванням посилання на thisключове слово дає результат 'bbb bbb':

class BBB : AAA
{
    public override void MyMethod(string s = "bbb")
    {
        base.MyMethod(s);
    }

    public override void MyMethod2()
    {
        this.MyMethod(); //added this keyword here
    }
}

Одне з речей, що це означає, це те, що ви завжди повинні використовувати thisключове слово, коли ви викликаєте властивості або методи поточного екземпляра класу як найкращу практику .

Я був би стурбований, якби ця неоднозначність методу base та child не викликала навіть попередження компілятора (якщо не помилки), але якщо це відбувається, то це, мабуть, було небаченим.

====================================================== ================

РЕДАГУВАТИ: Розгляньте нижче зразки уривків із цих посилань:

http://geekswithblogs.net/BlackRabbitCoder/archive/2011/07/28/c.net-little-pitfalls-default-parameters-are-compile-time-substitutions.aspx

http://geekswithblogs.net/BlackRabbitCoder/archive/2010/06/17/c-optional-parameters---pros-and-pitfalls.aspx

Підводний камінь: необов’язкові значення параметрів - це час компіляції. При використанні необов’язкових параметрів слід пам’ятати про одне і одне. Якщо ви пам’ятаєте про це одне, швидше за все, ви можете добре зрозуміти та уникнути будь-яких потенційних підводних каменів при їх використанні: Це одне: це необов’язкові параметри - час компіляції, синтаксичний цукор!

Підводний камінь: Остерігайтеся стандартних параметрів при реалізації спадщини та інтерфейсу

Тепер другі потенційні підводні камені пов’язані з успадкуванням та реалізацією інтерфейсу. Проілюструю головоломкою:

   1: public interface ITag 
   2: {
   3:     void WriteTag(string tagName = "ITag");
   4: } 
   5:  
   6: public class BaseTag : ITag 
   7: {
   8:     public virtual void WriteTag(string tagName = "BaseTag") { Console.WriteLine(tagName); }
   9: } 
  10:  
  11: public class SubTag : BaseTag 
  12: {
  13:     public override void WriteTag(string tagName = "SubTag") { Console.WriteLine(tagName); }
  14: } 
  15:  
  16: public static class Program 
  17: {
  18:     public static void Main() 
  19:     {
  20:         SubTag subTag = new SubTag();
  21:         BaseTag subByBaseTag = subTag;
  22:         ITag subByInterfaceTag = subTag; 
  23:  
  24:         // what happens here?
  25:         subTag.WriteTag();       
  26:         subByBaseTag.WriteTag(); 
  27:         subByInterfaceTag.WriteTag(); 
  28:     }
  29: }

Що сталося? Ну, навіть якщо об’єктом у кожному випадку є SubTag, тегом якого є “SubTag”, ви отримаєте:

1: Підтег 2: Базовий тег 3: ITag

Але пам’ятайте про те, щоб:

Не вставляйте нові параметри за замовчуванням в середину існуючого набору параметрів за замовчуванням, це може спричинити непередбачувану поведінку, яка не обов'язково може спричинити синтаксичну помилку - додати в кінець списку або створити новий метод. Будьте надзвичайно обережні, як ви використовуєте параметри за замовчуванням в ієрархіях та інтерфейсах успадкування - виберіть найбільш підходящий рівень, щоб додати значення за замовчуванням на основі очікуваного використання.

====================================================== ==========================

Question 8

Я думаю, це тому, що ці значення за замовчуванням фіксуються під час компіляції. Якщо ви використовуєте рефлектор, ви побачите наступне для MyMethod2 у BBB.

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

Question 9

Погодьтесь загалом з @Marc Gravell.

Однак я хотів би зазначити, що проблема досить стара у світі C ++ ( http://www.devx.com/tips/Tip/12737 ), і відповідь виглядає так: "на відміну від віртуальних функцій, які вирішуються під час запуску time, аргументи за замовчуванням вирішуються статично, тобто під час компіляції ". Отже, ця поведінка компілятора C # була прийнята навмисно через послідовність, не дивлячись на свою несподіваність.

Question 10

У будь-якому випадку це потребує виправлення

Я б точно розцінив це як помилку, або тому, що результати неправильні, або якщо результати очікуються, то компілятор не повинен дозволяти вам оголосити це як "перевизначення" або, принаймні, надати попередження.

Я рекомендую вам повідомити про це Microsoft.Connect

Але це правильно чи неправильно?

Однак щодо того, чи є це очікуваною поведінкою чи ні, давайте спочатку проаналізуємо два погляди на неї.

вважаємо, що ми маємо такий код:

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

Існує два способи його реалізації:

Факультативні аргументи розглядаються як перевантажені функції, що призводить до наступного:

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

Значення за замовчуванням вбудоване у абонента, що призводить до отримання такого коду:
```
void myfunc(int optional){ /* Some code here*/ } //Function implementation
myfunc(5); //Call and embed default arguments
```

Між двома підходами існує багато відмінностей, але спочатку ми розглянемо, як інтерпретує це середовище .Net.

У .Net ви можете замінити метод лише методом, що містить однакову кількість аргументів, але ви не можете замінити методом, що містить більше аргументів, навіть якщо всі вони є необов'язковими (що призведе до виклику, що має той самий підпис, що і перевизначений метод), скажімо, наприклад, що у вас є:
```
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)} 
```
Ви можете перевантажити метод із аргументами за замовчуванням іншим методом без аргументів (це має катастрофічні наслідки, як я обговорюю через кілька моментів), тому наступний код є законним:
```
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!
```
при використанні відображення завжди потрібно вказувати значення за замовчуванням.

Всього цього достатньо, щоб довести, що .Net взяв другу реалізацію, тому поведінка, яку побачив ОП, є правильною, принаймні згідно з.

Проблеми з підходом .Net

Однак існують реальні проблеми з підходом .Net.

Послідовність
- Як і в проблемі OP при перевизначенні значення за замовчуванням у успадкованому методі, результати можуть бути непередбачуваними
- Коли оригінальна імплантація значення за замовчуванням змінена, і оскільки абонентам не потрібно перекомпілювати, ми можемо отримати значення за замовчуванням, які більше не є дійсними
- Відображення вимагає вказати значення за замовчуванням, яке абонент не повинен знати
Порушення коду
- Коли у нас є функція з аргументами за замовчуванням, а останні ми додаємо функцію без аргументів, усі виклики тепер будуть спрямовуватися до нової функції, таким чином порушуючи весь існуючий код, без будь-якого повідомлення та попередження!
- Подібне трапиться, якщо пізніше ми вилучимо функцію без аргументів, тоді всі виклики автоматично перенаправлятимуться до функції із аргументами за замовчуванням, знову ж без попередження та попередження! хоча це може бути не намір програміста
- Крім того, це не повинен бути звичайний метод екземпляра, метод розширення буде робити ті самі проблеми, оскільки метод розширення без параметрів матиме перевагу над методом екземпляра з параметрами за замовчуванням!

Короткий зміст: ТРИМАЙТЕСЯ ВІД НЕОБОВ’ЯЗКОВИХ АРГУМЕНТІВ, І ВИКОРИСТОВУЙТЕ ЗАМЕЩЕННЯ ЗАВАНТАЖЕНЬ (ЯК САМО РОБИТЬ .NET FRAMEWORK)