Здравствуйте, _NN_, Вы писали:

_NN>CIL позволяет создавать статические методы в интерфейсе: How to: Create Interfaces with Static Methods via IL?.
_NN>Что думаете по поводу добавления этой фичи в язык ?
Думаем что статические методы в любом их обличии это зло, будь то в классах и тем более в интерфейсах.

Здравствуйте, Tom, Вы писали:

Tom>Думаем что статические методы в любом их обличии это зло, будь то в классах и тем более в интерфейсах.

При таком подходе функции без побочных эффектов зло и операторы тоже зло ?

Здравствуйте, _NN_, Вы писали:

_NN>Здравствуйте, Tom, Вы писали:

Tom>>Думаем что статические методы в любом их обличии это зло, будь то в классах и тем более в интерфейсах.

_NN>При таком подходе функции без побочных эффектов зло и операторы тоже зло ?
Причём тут функции без побочных эффектов. Статические функции никак не гарантируют отсутствие побочных эффектов.
Статические функции зло ибо несут проблемы при тестировании.

Здравствуйте, Tom, Вы писали:

_NN>>При таком подходе функции без побочных эффектов зло и операторы тоже зло ?
Tom>Причём тут функции без побочных эффектов. Статические функции никак не гарантируют отсутствие побочных эффектов.
Tom>Статические функции зло ибо несут проблемы при тестировании.

Да, если они недетерминированы и\или имеют побочные эффекты.

Здравствуйте, Tom, Вы писали:

Tom>Причём тут функции без побочных эффектов. Статические функции никак не гарантируют отсутствие побочных эффектов.
Ну так ничего не гарантируют, зато они не дают трогать объект.

Tom>Статические функции зло ибо несут проблемы при тестировании.
System.Math вы тоже не используете из-за статических методов ?

Здравствуйте, artelk, Вы писали:

A>Здравствуйте, Tom, Вы писали:

_NN>>>При таком подходе функции без побочных эффектов зло и операторы тоже зло ?
Tom>>Причём тут функции без побочных эффектов. Статические функции никак не гарантируют отсутствие побочных эффектов.
Tom>>Статические функции зло ибо несут проблемы при тестировании.

A>Да, если они недетерминированы и\или имеют побочные эффекты.
Статические методы создают проблемы при тестировании в любом случае, вне зависимости от их поведения.

Здравствуйте, _NN_, Вы писали:

_NN>Здравствуйте, Tom, Вы писали:

Tom>>Причём тут функции без побочных эффектов. Статические функции никак не гарантируют отсутствие побочных эффектов.
_NN>Ну так ничего не гарантируют, зато они не дают трогать объект.

Tom>>Статические функции зло ибо несут проблемы при тестировании.
_NN>System.Math вы тоже не используете из-за статических методов ?
В прямом виде — нет конечно, это моветон в 21-ом веке.
Простой пример гемороя статических методов.

Допустим у нас есть код некоего билинга который использует статические функции:
Наша задача покрыть функцию тестами, в данном случае есть 2 ветвления логики.
Прошу не стесняться и рассказать мне как вы напишете тесты в данной реализации функции с использованием статических методов...

void MakePayment(int account, DateTime paymentDate)
{
  var now = DateTime.UtcNow;

  if (now > paymentDate)
  {
    // some logic
  }
  else
  {
    // another logic
  }
}

Здравствуйте, Tom, Вы писали:

Tom>

Tom>void MakePayment(int account, DateTime paymentDate)
Tom>{
Tom>  var now = DateTime.UtcNow;

Tom>  if (now > paymentDate)
Tom>  {
Tom>    // some logic
Tom>  }
Tom>  else
Tom>  {
Tom>    // another logic
Tom>  }
Tom>}
Tom>

Выделенное — недетерминированная статическая функция (геттер свойства UtcNow).
Давай другой пример .

Здравствуйте, Tom, Вы писали:

Tom>Простой пример гемороя статических методов.

Tom>Допустим у нас есть код некоего билинга который использует статические функции:
Tom>Наша задача покрыть функцию тестами, в данном случае есть 2 ветвления логики.
Tom>Прошу не стесняться и рассказать мне как вы напишете тесты в данной реализации функции с использованием статических методов...
Microsoft Fakes ?

Я не против использования интерфейсов для тестов, тем более в этом случае.
Но отказ от статических методов означает, что придется отказаться от операторов , или они исключения ?

Здравствуйте, artelk, Вы писали:

A>Здравствуйте, Tom, Вы писали:

Tom>>

Tom>>void MakePayment(int account, DateTime paymentDate)
Tom>>{
Tom>>  var now = DateTime.UtcNow;

Tom>>  if (now > paymentDate)
Tom>>  {
Tom>>    // some logic
Tom>>  }
Tom>>  else
Tom>>  {
Tom>>    // another logic
Tom>>  }
Tom>>}
Tom>>

A>Выделенное — недетерминированная статическая функция (геттер свойства UtcNow).

A>Давай другой пример .
Ээээ? Реч идёт про статические функции? Я привёл пример, почему я должен другой давать — непонимаю.
Хотя дать другой — вариантов куча. Например код который лезет в базу и в зависимости от значения в базе что то делается.
Соответственно нам надо эмулировать различный результат...
Ключевое слово тут эмулировать. Если код написан в статическом методе — то он гвоздями прибит и никакими легитимными способами поменять его поведение нельзя.
Под легитимными понимается применение DI патерна

Здравствуйте, _NN_, Вы писали:

_NN>Здравствуйте, Tom, Вы писали:

Tom>>Простой пример гемороя статических методов.

Tom>>Допустим у нас есть код некоего билинга который использует статические функции:
Tom>>Наша задача покрыть функцию тестами, в данном случае есть 2 ветвления логики.
Tom>>Прошу не стесняться и рассказать мне как вы напишете тесты в данной реализации функции с использованием статических методов...
_NN>Microsoft Fakes ?
Именно они и являются идеальным примером того как статический метод может мешать при тестировании...

_NN>Я не против использования интерфейсов для тестов, тем более в этом случае.
Интерфейсы сами по себе решают много задач, и улучшения тестируенмости кода по сути является побочным еффектом тут.

_NN>Но отказ от статических методов означает, что придется отказаться от операторов , или они исключения ?
Просто не надо пользоваться перегрузкой операторов... зачем если для этого можно пользоваться методом.

Здравствуйте, Tom, Вы писали:

_NN>>Но отказ от статических методов означает, что придется отказаться от операторов , или они исключения ?
Tom>Просто не надо пользоваться перегрузкой операторов... зачем если для этого можно пользоваться методом.

Даже интересно стало, а вы как пишете
1.

var a = "a" + "b";

Или

var a = "a".Concat("b");

Аналогично в работе с другими классами типа Complex, BigInteger.

Т.е. вы считаете что введение перегрузки операторов в C# это ошибка дизайна ?

Здравствуйте, Tom, Вы писали:

A>>Выделенное — недетерминированная статическая функция (геттер свойства UtcNow).

A>>Давай другой пример .
Tom>Ээээ? Реч идёт про статические функции? Я привёл пример, почему я должен другой давать — непонимаю.
По тому, что тут проблема не со статической функцией.
А с глобальной переменной.

Tom>Хотя дать другой — вариантов куча. Например код который лезет в базу и в зависимости от значения в базе что то делается.
И тут тоже глобальная переменная.

Здравствуйте, Tom, Вы писали:

A>>Да, если они недетерминированы и\или имеют побочные эффекты.
Tom>Статические методы создают проблемы при тестировании в любом случае, вне зависимости от их поведения.

Хм... ИМХО это очень смелое заявление. Мне не понятно, какие проблемы в тестировании при наличии функций без побочных эффектов? Они сами тестируются элементарно, ну и нет проблем при тестировании кода, построенного на основе этих функций.

Это заявление ставит под сомнение всю идею функционального программирования, которое основано на функциях, которые по сути являются статическими. И оно же ставит под сомнение заявление вумных мира сего, которые говорят о важности композиции для построения сложных систем по принципу снизу вверх.

Я подозреваю, что ты подразумеваешь какой-то определенный контекст, но фраза в любом случае говорит также о вреде хелперов, методов расширения (того же LINQ-а) и тому подобных вещах, польза от которых очевидна.

Здравствуйте, _NN_, Вы писали:

_NN>Здравствуйте, Tom, Вы писали:

_NN>>>Но отказ от статических методов означает, что придется отказаться от операторов , или они исключения ?
Tom>>Просто не надо пользоваться перегрузкой операторов... зачем если для этого можно пользоваться методом.

_NN>Даже интересно стало, а вы как пишете
_NN>1.
_NN>

_NN>var a = "a" + "b";
_NN>

_NN>Или
_NN>

_NN>var a = "a".Concat("b");
_NN>

_NN>Аналогично в работе с другими классами типа Complex, BigInteger.

_NN>Т.е. вы считаете что введение перегрузки операторов в C# это ошибка дизайна ?
Я говорил про перегрузку операторов в своём собственном коде.
Понятно что для строк или чисел это допустимо.
Понятно что не надо впадать в маразм, до него надеюсь ещё лет 30-40

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, Tom, Вы писали:

A>>>Выделенное — недетерминированная статическая функция (геттер свойства UtcNow).

A>>>Давай другой пример .
Tom>>Ээээ? Реч идёт про статические функции? Я привёл пример, почему я должен другой давать — непонимаю.
WH>По тому, что тут проблема не со статической функцией.
WH>А с глобальной переменной.

Tom>>Хотя дать другой — вариантов куча. Например код который лезет в базу и в зависимости от значения в базе что то делается.
WH>И тут тоже глобальная переменная.
Ээээ, причём тут глобальные преременные.
Я совсем про другую проблему вещаю.
Я про то что статические методы ставят крест на DI/IoC и убивают все прелести данных патернов

Здравствуйте, SergeyT., Вы писали:

ST>Здравствуйте, Tom, Вы писали:

A>>>Да, если они недетерминированы и\или имеют побочные эффекты.
Tom>>Статические методы создают проблемы при тестировании в любом случае, вне зависимости от их поведения.

ST>Хм... ИМХО это очень смелое заявление. Мне не понятно, какие проблемы в тестировании при наличии функций без побочных эффектов? Они сами тестируются элементарно, ну и нет проблем при тестировании кода, построенного на основе этих функций.

Ты не совсем понимаешь о чём именно я говорю.
Я говорю не о том что статические функции тяжело тестировать.
Я говорю о том что код который использует статические функции тяжело тестировать потому что поведение этих статических функций невозможно поменять не применяя грязных хаков аля profiler api.
Т.е. если ты считаешь что в тестах никогда не надо подменять поведение даже строго детерминированной функции то можно считать что статические функции ок.


ST>Это заявление ставит под сомнение всю идею функционального программирования, которое основано на функциях, которые по сути являются статическими. И оно же ставит под сомнение заявление вумных мира сего, которые говорят о важности композиции для построения сложных систем по принципу снизу вверх.

ST>Я подозреваю, что ты подразумеваешь какой-то определенный контекст, но фраза в любом случае говорит также о вреде хелперов, методов расширения (того же LINQ-а) и тому подобных вещах, польза от которых очевидна.

см выше.

Здравствуйте, Tom, Вы писали:

_NN>>Аналогично в работе с другими классами типа Complex, BigInteger.

_NN>>Т.е. вы считаете что введение перегрузки операторов в C# это ошибка дизайна ?
Tom>Я говорил про перегрузку операторов в своём собственном коде.
А чем отличается свой код от чужого ?
Может как раз я пишу "чужой" код

Tom>Понятно что для строк или чисел это допустимо.
И еще для остальных типов где это положенно.

Здравствуйте, _NN_, Вы писали:

_NN>Здравствуйте, Tom, Вы писали:

_NN>>>Аналогично в работе с другими классами типа Complex, BigInteger.

_NN>>>Т.е. вы считаете что введение перегрузки операторов в C# это ошибка дизайна ?
Tom>>Я говорил про перегрузку операторов в своём собственном коде.
_NN>А чем отличается свой код от чужого ?
тем что ты не реализуешь оператор + для строк и чисел

Здравствуйте, Tom, Вы писали:

Tom>>>Хотя дать другой — вариантов куча. Например код который лезет в базу и в зависимости от значения в базе что то делается.
WH>>И тут тоже глобальная переменная.
Tom>Ээээ, причём тут глобальные преременные.
Tom>Я совсем про другую проблему вещаю.
Tom>Я про то что статические методы ставят крест на DI/IoC и убивают все прелести данных патернов

DI/IoC нужен далеко не всегда, говорю как человек с диагнозом "ООП головного мозга".