Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Тут интересно посмотреть на его реализацию:
Да, именно поэтому я привёл ссылку на неё.
Там проблема даже не в том, чтобы убрать эту "срань", а в том, что нет способа добавить в эту срань даункаст к чему-то ещё, что позволит обойтись без итерирования.
Например, ImmutableList реализует IReadOnlyCollection, а не ICollection — и всё, приплызд.

НС>Это ты слишком оптимистичен. Мы вот уже год пытаемся с 3.1 слезть, но пока только отдельные сервисы переползли. Геморой начался с апгрейда SDK, но его со второго подхода удалось победить (на первом подходе что то сломалось у билд-агентов, а у девопсов, как обычно, есть более срочные задачи чтобы с этим разбираться). Потом ждали когда сборку базовых образов в порядок приведу, чтобы легко можно было добавить версию с 6.0. Потом что то в ASP.NET отломалось (без breaking changes не обошлось). Вобщем, уже 7.0 зарелизен, а мы все еще на 6.0 переползаем с 3.1.
НС>С FW да, попроще было. Но и там МС подкладывал свинью в виде совместимости со старыми версиями ОС. И продолжает подкладывать — 4.8.1 требует WIn11/WinServer2019. Последнее может быть большой проблемой, ибо работает — не трожь.
Ок, согласен, погорячился.

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

НС>>Это прям свежий звук в проектировании софта, дизайн для тех кто опытнее и талантливее.
C>Особый дизайн не нужен, просто не мешай.

Это так не работает. Если что то можно сделать неправильно, оно обязательно будет сделано неправильно (если, конечно, твоим кодом пользуются другие люди). После чего ты будешь расхлебывать свою ориентацию на более опытных и талантливых по полной.
Что особенно забавно, даже если ты пишешь код исключительно для себя (а кто может быть опытнее и талантливее себя любимого?), то если вдруг такое случится, что ты вернешься к этому коду через годик-другой, то внезапно окажется что ты не тот опытный и талантливый, на которого был рассчитан тот дизайн. И, в лучшем случае, это даст тебе возможность стать чуть опытнее. А в худшем через год-два oops!, I did it again.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Статический хелпер не обеспечимвает полиморфизма.

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

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

C>Это у тебя тяжелый случай синдрома "чем больше абстракций, тем лучше".

У меня синдромов нет. Если абстракции на уровне типов не нужны я и функциями могу прекрасно обойтись. И интерфейсы использовать не буду, если они не нужны.

А вот у тебя явные проблемы в вопросе абстракций есть, что и послужило причиной к этому флэйму.

C>В C# нет множественного наследования реализаций.

Да. И дефолтные члены интерфейсов этого не изменяют.

C>Да, ни у кого. В том числе у тех, кто намного опытнее и талантливее тебя.

И у таких тоже. Но это, явно, не твой случай.

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

C>В C# нет множественного наследования реализаций.

Не совсем. В Delphi для ком интерфейса есть директива Implements. То есть за реализацию интерфейса отвечало поле объекта.
С приходом SG можно генерить не только реализацию интерфейса, но и методы и свойства класса типа поля.
По сути это и будет аналогом множественного наследования C++

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

K>Кто не хочет писать свою оптимальную реализацию или его устраивает некая стандартная, в реализации метода просто вызывает этот хелпер.

Я тут рядом привел исходный код Enumerable.Count(). Сможешь его переписать со статическим хелпером?

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Это так не работает. Если что то можно сделать неправильно, оно обязательно будет сделано неправильно (если, конечно, твоим кодом пользуются другие люди). После чего ты будешь расхлебывать свою ориентацию на более опытных и талантливых по полной.

Я уже понял, что твоя основная задача — прикрыть себе задницу

НС>А в худшем через год-два oops!, I did it again.

Ни разу не случалось.

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

VD>У меня синдромов нет. Если абстракции на уровне типов не нужны я и функциями могу прекрасно обойтись. И интерфейсы использовать не буду, если они не нужны.

Сам написал "раз ты завёл интерфейсы, то работать с классами иже не имеешь права", никто за язык не тянул.
Путаешься в показаниях

VD>А вот у тебя явные проблемы в вопросе абстракций есть, что и послужило причиной к этому флэйму.

Ага-ага. Кто-то решил пихать в интерфейсы функции, которым там не место, и почему-то ему взбрело в голову, что это и есть основной вариант использования интерфейсов. А проблемы почему-то у меня

VD>И у таких тоже.

Да, и и таким тоже ты будешь ставить палки в колеса.

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

VD>Судя по твоей критике ты пока что до этих фич не дорос.

Тут есть два варианта — либо не догнал, либо перегнал. Все будет нравиться только в том случае, если ты находишь ровно на том же уровне.
И да, к тебе это тоже относится.

Здравствуйте, Ночной Смотрящий, Вы писали:

НС>Я тут рядом привел исходный код Enumerable.Count(). Сможешь его переписать со статическим хелпером?

Нет.
А ты сможешь его переписать, не превращая IEnumerable в IReadOnlyCollection?

C>

C> static void Main(string[] args)
C> {
C> var obj = new TestClass();
C> obj.Method(); // error
C> }

C> interface ITest
C> {
C> void Method()
C> {
C> }
C> }

C> class TestClass : ITest
C> {
C> }

  static void Main (string[]args)
  {
    var obj = new TestClass();
      obj.Method(); // error
  }
  interface ITest
  {
    void Method();
  }

  class TestClass:ITest
  {
      void ITest.Method() {}
  }

Есть пять областей видимости методов: public, protected, internal, private и реализации интерфейсов.
Вызывать у объекта мы можем только "видимые" методы. В вашем примере публичные.
Есть соглашение, что публичный метод с совпадающей сигнатурой может использоваться как метод реализации интерфейса.
Но почему решили, что должно быть верно обратное?

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

Doc>Это про добавление методов без ломки совместимости.

Что в общем то полный изврат, но кого волнуют такие мелочи?