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

S>>Ну, если вам нравятся object и collection initializers — почему нет?
C>А оно будет работать с readonly?

Там немного своя механика.

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

S>>Почему же неразрываемая и не настраиваемая -- а паттерн декоратор на что?

НС>А при чем тут наследование?

Декоратор это один из методов реализации подтипа. Сохраняем все основные операции, только немного модифицируем поведение. Тип — это семейство объектов со схожим поведеним.
Стратегия про то же — реализация подтипа.

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

S>>В любом случае, про гитхаб слышали? Заводили там когда-нибудь issue для бага или улучшения?

C>Читал. Там дуб. Непрошибаемый. По каким принципам они выбирают что делать — видимо, исключительно по желанию чьей-то левой пятки. Потому что даже такая элементарщину, как унифицировать интерфейс Array и List, они решили не делать. Даже когда начали делать с нуля корку.

Это надо было делать во фремворке 1.0. Дальше это обросло чудовищным количеством кода. И если унифицировать интерфейс Array и List это может дать неопределенное количество поломок с обратной совместимостью.

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

НС>>Слишком сильная связность между предком и наследником, слишком низкая гибкость такой связи, неразрываемая и не настраиваемая связь между наследованием контракта и наследованием реализации.

S>Почему же неразрываемая и не настраиваемая -- а паттерн декоратор на что?

Паттерн декоратор это библиотечный способ решить проблему с наследованием, как и стратегия

В ООП класс это одновременно тип и модуль. Экземпляр он тоже модуль в т.ч. Вот такая двойственность неискоренима.
С наследованием всё хорошо, если ты используешь классы только как типы, а наследование только как subtype. И точно так же всё хорошо, если используешь классы только модули, а наследование — только как расширение модуля.
Штука в том, что таких задач крайне мало. А раз так, то у тебя всегда в той или иной степени смешиваются тип и модуль.

Интерфейс это ровно та же хрень — и класс и модуль. Соответсвенно, отсюда ясно, что расширяя интерфейс-тип как модуль, мы вносим ровно тот же хаос, что и в обычном наследовании реализации

Вот пример:

interface ImmutableRecord {
   readThis; // определили вполне конкретную семантику
   readThat;
}

interface MutableRecord extends ImmutableRecord {
   writeThis;  // опаньки, сломали семантику
   writeThat;
}

На самом деле я считаю, что такое состояние дел нормално. Инструменты, которые не дают ошибиться, не дают сломать, вобщем мало кому нужны.

Потому что в общем случае сконструировать обьект-потомок используя конструктор родителя невозможно? Родитель не знает что в потомка накидали, он вообще про его наличие ничего не знает.
По-моему хорошая причина.

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

C>Потому что даже такая элементарщину, как унифицировать интерфейс Array и List, они решили не делать.

В каком смысле унифицировать? Они оба реализуют IList.

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

S>У вас нет ни одной точки, в которой для вашей коллекции вызывается конструктор с нестандартным компарером.
S>Через полгода, когда вы поняли, что для вашей коллекции важно использовать какой-то конкретный компарер, у вас уже есть неизвестное количество кода, заточившегося под этот конструктор.

Ты уж определись — или трусы, или крестик.

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

НС>Плохая привычка.

"Я тут подумал и решил, что мне лень это делать, а пользователи пусть сами выкручиваются" — намного хуже.

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

НС>Там немного своя механика.

И потом его все равно можно изменить. Идиоты.

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

T>Потому что в общем случае сконструировать обьект-потомок используя конструктор родителя невозможно? Родитель не знает что в потомка накидали, он вообще про его наличие ничего не знает.

Может тогда и readonly не нужен, раз его нельзя использовать для всех значений во всех мыслимых случаях?

T>По-моему хорошая причина.

Идиотская.

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

P>Это надо было делать во фремворке 1.0. Дальше это обросло чудовищным количеством кода. И если унифицировать интерфейс Array и List это может дать неопределенное количество поломок с обратной совместимостью.

Просто добавить методы с одинаковыми сигнатурами, где их еще нет.
.Sort() вдобавок к статическому Array.Sort() и так далее.

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

НС>В каком смысле унифицировать? Они оба реализуют IList.


Как ты вызываешь для них сортировку, например?

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

X>Идиоматичней было бы так:

Это ты какую-то фигню придумал. Надо так:

    public MyException(string? message = null, Exception? innerException = null) : base(message, innerException)
    {
           // any additional init goes here ... 
           Console.WriteLine("MyException was created at {0}", DateTime.UtcNow);
    }
    
    ...

X>Но это рушит чью-то картину необходимости и тем более корректности автоматической генерации конструкторов.

На самом деле нет

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

НС>Плохая привычка.

Ну, тут главное не увлекаться. Я же не пишу на всякий случай километры кода, а небольшие плюшки за 5 минут чего бы не написать?

НС>Возвращаться и дописывать — это нормально, рефакторинг — наше все.
НС>Намного лучше, чем сделать слишком универсальный, а потому сложный и неудобный код, а эту универсальность потом не использовать.

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

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

НС>Слишком сильная связность между предком и наследником, слишком низкая гибкость такой связи

Общие слова.

НС>неразрываемая и не настраиваемая связь между наследованием контракта и наследованием реализации.

Интерфейсы, не слышал?

НС>Пропустил вечный флейм про то, кто у кого наследник, прямоугольник у квадрата или квадрат у прямоугольника?

И правильно, потому что проблема высосана из пальца.

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

НС>>Плохая привычка.
C>"Я тут подумал и решил, что мне лень это делать, а пользователи пусть сами выкручиваются" — намного хуже.

При чем тут пользователи?

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

НС>>Плохая привычка.
K>Ну, тут главное не увлекаться. Я же не пишу на всякий случай километры кода, а небольшие плюшки за 5 минут чего бы не написать?

Антон вроде понятно объяснил. 5 минут написать, потом 5 дней потерять на поддержке.

НС>>Возвращаться и дописывать — это нормально, рефакторинг — наше все.
НС>>Намного лучше, чем сделать слишком универсальный, а потому сложный и неудобный код, а эту универсальность потом не использовать.
K>Если сделал сразу, то больше вероятность что рефакторинг и доработка не потребуются

Не надо боятся рефакторинга и воспринимать его как зло. Качество кода, которое достигается регулярным рефакторингом недостижимо никакими другими способами.

K>, а значит не нужно будет лезть в старый проверенный код и что-то там менять

Не бывает. Не бывает чтобы старый код долго жил без накопления техдолга.

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

НС>>В каком смысле унифицировать? Они оба реализуют IList.
C>
C>Как ты вызываешь для них сортировку, например?

Т.е. проблема исключительно в сортировке и ее перфомансе? Или есть еще что то?

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

НС>>неразрываемая и не настраиваемая связь между наследованием контракта и наследованием реализации.
C>Интерфейсы, не слышал?

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

НС>>Пропустил вечный флейм про то, кто у кого наследник, прямоугольник у квадрата или квадрат у прямоугольника?
C>И правильно, потому что проблема высосана из пальца.

Да? Ну расскажи как правильно тогда.

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

НС>При чем тут пользователи?

При том, что твоим кодом может еще кто-то пользоваться. Или ты пишешь только в /dev/null ?