Здравствуйте, Codealot, Вы писали:
C>есть внятные объяснения?
Явное наследование через base() есть.
Если сделать неявное, получается борода:
1. Возьмем 3 сборки:
* ParentAssembly с ParentClass(int x)
* ChildAssembly с ChildClass(int x) : base(x), сгенерированный компилятором
* UserAssembly, создающую ChildClass.
2. Меняем в ParentAssembly int x -> string x.
3. Пересобираем ParentAssembly и ChildAssembly. Все собралось без ошибок и зарелизилось.
4. Где-то в другой временной зоне громко ругается разработчик UserAssembly, который начал вываливаться с MethodNotFoundException.
Явное определение конструкторов (которое на раз генерируется IDE) это предотвращает — ChildAssembly выдаст ошибку на этапе компиляции, разработчик вспомнит, что это public API и откатит все взад.
Если очень надо и часто меняются параметры — сделай wrapper class, как с EventArgs.
Здравствуйте, Quebecois, Вы писали:
Q>1. Возьмем 3 сборки: Q>
Q>* ParentAssembly с ParentClass(int x) Q>* ChildAssembly с ChildClass(int x) : base(x), сгенерированный компилятором Q>* UserAssembly, создающую ChildClass. Q>Q>2. Меняем в ParentAssembly int x -> string x. Q>3. Пересобираем ParentAssembly и ChildAssembly. Все собралось без ошибок и зарелизилось. Q>4. Где-то в другой временной зоне громко ругается разработчик UserAssembly, который начал вываливаться с MethodNotFoundException.
Q>Явное определение конструкторов (которое на раз генерируется IDE) это предотвращает — ChildAssembly выдаст ошибку на этапе компиляции, разработчик вспомнит, что это public API и откатит все взад.
Ну дык ctor ParentClass тоже public api, но разработчик спокойно его поменял.
Re: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
C>есть внятные объяснения?
Quebecois прекрасно всё объяснил, но скорее с практической точки зрения. Public API не должен меняться вообще, если так по-хорошему.
В теории, смысл такой:
{{ базовый класс
констр 1
констр 2
}}
{{ потомок
констр 3
}}
Когда ты создаёшь класс-потомок, ты наследуешь поведение базы. НО(!) никто не сказал, что базовые конструкторы вообще подходят под конструирование потомка! Если ты ввёл "единственно правильный" констр 3, то юзер класса "потомок" вообще не должен никогда видеть констр 1! Что, собственно, язык и делает. Хочешь "пробросить" конструктор — не вопрос, просто создай его руками.
Что в C# налажали, так это вызов самих конструкторов. Если я правильно ошибаюсь, в Delphi можно вызывать базовый конструктор из любого места текущего конструктора. В C# это возможно только в начале. А может это я с D перепутал.
Здравствуйте, Baiker, Вы писали:
B>Что в C# налажали, так это вызов самих конструкторов. Если я правильно ошибаюсь, в Delphi можно вызывать базовый конструктор из любого места текущего конструктора. В C# это возможно только в начале. А может это я с D перепутал.
В жаве та же фигня. Капец бесит.
Так можно
MyCtor() {
super(something());
}
А так нельзя
MyCtor() {
int s = something();
super(s);
}
Лавров.jpg
Re[2]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Baiker, Вы писали:
B>Что в C# налажали, так это вызов самих конструкторов. Если я правильно ошибаюсь, в Delphi можно вызывать базовый конструктор из любого места текущего конструктора. В C# это возможно только в начале.
И зачем эта фича нужна?
Какие-то минимальные расчёты можно и в текущем варианте передать в вызове base.
Если там какая-то сложная логика, то вообще странно в конструктор это пихать.
Тут уже какая-нибудь фабрика нужна, которая и асинхронность сможет предоставить.
Re[2]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Quebecois, Вы писали:
Q>3. Пересобираем ParentAssembly и ChildAssembly. Все собралось без ошибок и зарелизилось. Q>4. Где-то в другой временной зоне громко ругается разработчик UserAssembly, который начал вываливаться с MethodNotFoundException.
А если ты сигнатуру метода в ParentAssembly.ParentClass поменяешь, который вызывается из UserAssembly?
Ад пуст, все бесы здесь.
Re[5]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, νsb, Вы писали:
S>>Ога, класс, особенно если something виртуальный метод. νsb>При чём тут это. Виртуальные методы нельзя вызывать, пока не вызвал конструктор базового объекта.
Если компилятор такое поймать сможет, то да, проблем нет, иначе -- хреново.
Кодом людям нужно помогать!
Re[6]: почему в C# до сих пор нет наследования конструкторов
Здравствуйте, Sharov, Вы писали:
S>>>Ога, класс, особенно если something виртуальный метод. νsb>>При чём тут это. Виртуальные методы нельзя вызывать, пока не вызвал конструктор базового объекта.
S>Если компилятор такое поймать сможет, то да, проблем нет, иначе -- хреново.
Сможет, конечно. Ну в жаве по крайней мере может.
Проблема возникает, когда нужно что-то не совсем тривиальное. К примеру в конструктор базового класса нужно передавать два параметра. И чтобы эти параметры вычислить, нужна еще пара строк, которые никакие виртуальные методы вызывать не будут, просто какие-то простые преобразования от параметров конструктора. Сейчас это в жаве никак не сделаешь, ну только вычислять это два раза в статическом методе, что смотрится очень некрасиво. Или заменить конструктор на статический метод, который будет конструировать объект, что тоже кажется некрасивым усложнением на ровном месте.
Условно:
Могло бы быть:
MyCtor(double d) {
double a = atan(d);
double s = sin(a);
double c = cos(a);
super(s, c);
}
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, Quebecois, Вы писали:
Q>>3. Пересобираем ParentAssembly и ChildAssembly. Все собралось без ошибок и зарелизилось. Q>>4. Где-то в другой временной зоне громко ругается разработчик UserAssembly, который начал вываливаться с MethodNotFoundException.
C>А если ты сигнатуру метода в ParentAssembly.ParentClass поменяешь, который вызывается из UserAssembly?
Методы на уровне метаданных референсятся из ParentAssembly. Конструкторы, физически находящиеся в ChildAssembly — из нее. Поломка обратной совместимости между ChildAssembly и UserAssembly при модификации BaseAssembly и без модификации ChildAssembly — архитектурный косяк. Еще получается, что из одних и тех же исходников ChildAssembly будет собираться 2 несовместимые друг с другом версии сборки, в зависимости от того, что было в BaseAssembly.
Вообще, золотое правило дизайна сложных систем — каждое изменение отдельного параметра должно иметь минимальные по сложности (и предсказуемости) последствия. Иначе начинается каскад непредвиденных проблем при каждом чихе. В текущей реализации изменение сигнатуры конструктора повлияет только на конкретные методы, конкретно его вызывающие. Они вылетят с ошибками компиляции и необходимость их правки защитит от непреднамеренной поломки на порядок большего количества кода.
Ну и дисклеймер: такие решения 100% субъективны — это judgment call архитектора в плане удобство vs. вероятность глюков. Точек зрения об идеальном балансе тут может быть больше, чем разработчиков, и спорить о них — дело неблагодарное. Обычно, чья зона ответственности — тот и решает (и несет ответственность). Я лишь попытался объяснить точку зрения человека, принявшего решение не наследовать автоматически конструкторы.
Здравствуйте, karbofos42, Вы писали:
K>Здравствуйте, Quebecois, Вы писали:
Q>>Явное наследование через base() есть.
K>Если много конструкторов, то замучаешься их вот так дублировать в каждом наследнике и потом поддерживать.
Я же написал ниже: делаешь BaseClass(ConstructionRequest rq) и передаешь его. Runtime overhead будет минимальный, поддерживать ничего не надо. Вся система EventHandler-ов на этом построена.
K>В С++ есть вот такая штука: K>https://learn.microsoft.com/en-us/cpp/cpp/constructors-cpp?view=msvc-170#inheriting_constructors K>
K>class Derived : Base
K>{
K>public:
K> // Inherit all constructors from Base
K> using Base::Base;
K>...
K>
В плюсах семантика другая — чтобы скомпилировать Derived из исходников, надо рекурсивно распарсить Base и еще миллион заголовков. C# специально разработали так, чтобы вместо этого хватало метаданных сборок из references с хеш-индексами. В итоге, компиляция быстрее на несколько порядков.
Re: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
C>есть внятные объяснения?
А можно поподробнее объяснить, что имеется в виду?
Какой сценарий использования предполагается?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Q>* ParentAssembly с ParentClass(int x) Q>* ChildAssembly с ChildClass(int x) : base(x), сгенерированный компилятором Q>* UserAssembly, создающую ChildClass. Q>Q>2. Меняем в ParentAssembly int x -> string x. Q>3. Пересобираем ParentAssembly и ChildAssembly. Все собралось без ошибок и зарелизилось. Q>4. Где-то в другой временной зоне громко ругается разработчик UserAssembly, который начал вываливаться с MethodNotFoundException.
Простите, но вы неправы. Описанный вами сценарий и не должен работать, и не работает в С# независимо от наличия автоматически унаследованных конструкторов.
Корень проблемы, которую вы описываете в своём примере, не в том, что там что-то автоматически отнаследовалось, а в том, что владелец UserAssembly пытается использовать её без перекомпиляции после того, как одна из зависимостей (ChildAssembly) изменилась.
Дотнет не рассчитан на такое использование. Правило большого пальца: если изменилась хотя бы одна из зависимостей, проект нужно пересобирать.
Исключения из этого правила очень редки, и требуют специальных усилий. Ну, там, к примеру, если вы пишете приложение, которое должно уметь работать с плагинами — в некотором смысле, плагины являются для вас зависимостями; но там вы будете прилагать специальные меры как со стороны приложения, так и со стороны плагинов (в виде набора ограничений на типы, экспортируемые из плагина) для предотвращения проблем с версионированием метаданных.
Авторы .Net, конечно же, предпринимают усилия при публикации апдейтов — так, чтобы приложения, собранные под .Net 6.0.0, продолжали работать под .Net 6.0.3 без перекомпиляции.
И эти усилия, в частности, включают в себя запрет на внезапные модификации сигнатур конструкторов.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Quebecois, Вы писали:
Q>Я же написал ниже: делаешь BaseClass(ConstructionRequest rq) и передаешь его. Runtime overhead будет минимальный, поддерживать ничего не надо. Вся система EventHandler-ов на этом построена.
ну, допустим, у меня есть базовый класс коллекции со следующими конструкторами:
public CollectionBase();
public CollectionBase(int capacity);
public CollectionBase(params T[] items);
public CollectionBase(IEnumerable<T> items);
public CollectionBase(IReadOnlyCollection<T> items);
как мне сделать наследника, у которого будут все эти конструкторы продублированы? Или как будет выглядеть аналог с ConstructionRequest?
Q>В плюсах семантика другая — чтобы скомпилировать Derived из исходников, надо рекурсивно распарсить Base и еще миллион заголовков. C# специально разработали так, чтобы вместо этого хватало метаданных сборок из references с хеш-индексами. В итоге, компиляция быстрее на несколько порядков.
Методы же как-то наследуются, а конструкторы чем-то принципиально от методов отличаются?
Здравствуйте, Sinclair, Вы писали: S>Простите, но вы неправы. Описанный вами сценарий и не должен работать, и не работает в С# независимо от наличия автоматически унаследованных конструкторов.
Работает.
пруф
Минимальное репро — распакуется через patch -p1 < RefTest.patch:
UserAssembly создает экземпляр ChildClass без прямого reference на ParentAssembly. Т.е. на уровне метаданных достаточно вещей, вытянутых из ChildAssembly. S>Корень проблемы, которую вы описываете в своём примере, не в том, что там что-то автоматически отнаследовалось, а в том, что владелец UserAssembly пытается использовать её без перекомпиляции после того, как одна из зависимостей (ChildAssembly) изменилась.
Я не говорю, что это хорошая user practice. Это просто пример того, что сейчас работает, и сломалось бы при добавлении наследования конструкторов. S>Дотнет не рассчитан на такое использование. Правило большого пальца: если изменилась хотя бы одна из зависимостей, проект нужно пересобирать. S>Исключения из этого правила очень редки, и требуют специальных усилий. Ну, там, к примеру, если вы пишете приложение, которое должно уметь работать с плагинами — в некотором смысле, плагины являются для вас зависимостями; но там вы будете прилагать специальные меры как со стороны приложения, так и со стороны плагинов (в виде набора ограничений на типы, экспортируемые из плагина) для предотвращения проблем с версионированием метаданных.
Я про плагины и говорил. Сейчас достаточно публичные интерфейсы вынести в отдельную assembly и не трогать существующие типы в ней. С наследованием это перестанет работать.
Здравствуйте, Quebecois, Вы писали: Q>Работает.
Я неудачно выразился. Этот способ может работать. А может и не сработать, причём большим количеством разнообразных способов.
Например, может вылететь исключение с method not found. А может молча выбраться не тот метод, который ожидает пользователь.
Ограничения, при которых можно безопасно использовать из сборки A сборку B после внесения в метаданные B изменений без перекомпиляции A, перечислить довольно сложно.
И изменение сигнатуры конструктора в них явно не входит.
Именно отсюда правило большого пальца: всегда перекомпилируем проект при изменении в любой из зависимостей.
Вот в вашем примере совершенно не нужно привлекать какую-то ParentAssembly.
Достаточно просто иметь ChildAssembly с классом ChildClass, отнаследованным напрямую от object.
Теперь мы заменяем сигнатуру конструктора в ChildClass c ChildClass(int x) на ChildClass(string x).
Совершенно неважно, сгенерирован ли этот конструктор автоматически языком или вручную пользователем. Результат будет одинаковым — MethodNotFound.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Дотнет не рассчитан на такое использование. Правило большого пальца: если изменилась хотя бы одна из зависимостей, проект нужно пересобирать. S>Исключения из этого правила очень редки, и требуют специальных усилий. Ну, там, к примеру, если вы пишете приложение, которое должно уметь работать с плагинами — в некотором смысле, плагины являются для вас зависимостями; но там вы будете прилагать специальные меры как со стороны приложения, так и со стороны плагинов (в виде набора ограничений на типы, экспортируемые из плагина) для предотвращения проблем с версионированием метаданных.
Здравствуйте, Sinclair, Вы писали:
S>Ограничения, при которых можно безопасно использовать из сборки A сборку B после внесения в метаданные B изменений без перекомпиляции A, перечислить довольно сложно. S>И изменение сигнатуры конструктора в них явно не входит. S>Именно отсюда правило большого пальца: всегда перекомпилируем проект при изменении в любой из зависимостей.
По-моему, мы о разных вещах говорим. .Net позволяет UserAssembly инстанциировать класс из ChildAssembly, унаследованный от ParentAssembly, без ссылки UserAssembly->ParentAssembly.
S>Вот в вашем примере совершенно не нужно привлекать какую-то ParentAssembly. S>Достаточно просто иметь ChildAssembly с классом ChildClass, отнаследованным напрямую от object. S>Теперь мы заменяем сигнатуру конструктора в ChildClass c ChildClass(int x) на ChildClass(string x). S>Совершенно неважно, сгенерирован ли этот конструктор автоматически языком или вручную пользователем. Результат будет одинаковым — MethodNotFound.
Точно о разных вещах. ParentAssembly позволяет получить такую диаграмму зависимостей (references из метаданных):
Еще раз, прямой ссылки из UserAssembly на ParentAssembly нет, но это не мешает создавать класс, пронаследованный оттуда через ChildAssembly.
Реалистичный пример: ParentAssembly — внутренняя сборка продукта с внутренним функционалом. ChildAssembly — сборка с интерфейсами для плагинов. UserAssembly — плагин, не имеющий понятия о ParentAssembly.
Если разработчик продукта не хочет ломать обратную совместимость с UserAssembly, ему достаточно придерживаться простого правила: не менять/удалять ничего из ChildAssembly. Добавлять новые классы и интерфейсы — да. Менять/удалять — нет. Это легко соблюдать и легко проверять в процессе ревью. При этом, код внутри приватной ParentAssembly можно кромсать, как хочется — плагины на нее не ссылаются и изменения их не затронут.
Если мы добавляем сюда наследование конструкторов — получается, что поменяв конструктор в приватной ParentAssembly, мы неявно поменяли публичный интерфейс ChildAssembly, и сломали плагин. Ревью это не отловит, потому что исходники ChildAssembly мы не меняли.
На практике, ссылки из interface assemblies в private — это кривой паттерн, но текущая семантика его не ломает, а добавление наследования конструкторов — сломает. Или, выражаясь в Ваших терминах — это сделает нерекурсивное правило большого пальца рекурсивным.
Здравствуйте, Quebecois, Вы писали:
Q>По-моему, мы о разных вещах говорим. .Net позволяет UserAssembly инстанциировать класс из ChildAssembly, унаследованный от ParentAssembly, без ссылки UserAssembly->ParentAssembly.
Нет, об одном и том же.
Ссылка на ParentAssembly тут ни при чём.
Q>Точно о разных вещах. ParentAssembly позволяет получить такую диаграмму зависимостей (references из метаданных):
Q>UserAssembly -> ChildAssembly Q>ChildAssembly -> ParentAssembly
Q>Еще раз, прямой ссылки из UserAssembly на ParentAssembly нет, но это не мешает создавать класс, пронаследованный оттуда через ChildAssembly.
И это — совершенно неважно.
Q>Реалистичный пример: ParentAssembly — внутренняя сборка продукта с внутренним функционалом. ChildAssembly — сборка с интерфейсами для плагинов. UserAssembly — плагин, не имеющий понятия о ParentAssembly. Q>Если разработчик продукта не хочет ломать обратную совместимость с UserAssembly, ему достаточно придерживаться простого правила: не менять/удалять ничего из ChildAssembly. Добавлять новые классы и интерфейсы — да. Менять/удалять — нет. Это легко соблюдать и легко проверять в процессе ревью. При этом, код внутри приватной ParentAssembly можно кромсать, как хочется — плагины на нее не ссылаются и изменения их не затронут.
Нет, это не так легко соблюдать в процессе ревью, как вам кажется.
Q>Если мы добавляем сюда наследование конструкторов — получается, что поменяв конструктор в приватной ParentAssembly, мы неявно поменяли публичный интерфейс ChildAssembly, и сломали плагин. Ревью это не отловит, потому что исходники ChildAssembly мы не меняли.
Наследование конструкторов ничего не меняет в сути проблемы. Повторю, на всякий случай, основное утверждение: любое изменение метаданных в зависимости требует перекомпиляции вашей сборки. В том числе и неявное.
То, что вы полагаете, что код ревью на уровне исходников ChildAssembly вас в этой ситуации спасёт — опасное заблуждение. Q>На практике, ссылки из interface assemblies в private — это кривой паттерн, но текущая семантика его не ломает, а добавление наследования конструкторов — сломает. Или, выражаясь в Ваших терминах — это сделает нерекурсивное правило большого пальца рекурсивным.
Оно и так рекурсивно.
Смотрите:
ParentAssembly v1:
public class Parent
{
public virtual void Foo() => Console.WriteLine("foo");
}
ChildAssembly:
public class Child: Parent
{
}
UserAssembly v1:
var c = new ChildClass();
c.Foo();
ParentAssembly v2:
public class Parent
{
public void Foo(string x) => Console.WriteLine(x);
}
При запуске UserAssembly с ParentAssembly v2 вы получите MethodNotFound. Независимо от того, перекомпилируете ли вы ChildAssembly или нет. Несмотря на то, что исходный код ChildAssembly вовсе не менялся. И это вам ещё повезёт — потому, что вы, по крайней мере, заметите неладное.
Я могу вам накидать более тонких примеров, в которых будет вызываться не тот метод, которого вы ожидаете. Или тот метод, но с неверными аргументами.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Оно и так рекурсивно. S>Смотрите:
S>UserAssembly v1: S>
S>var c = new ChildClass();
S>c.Foo();
S>
Оно не соберется без ссылки UserAssembly -> ParentAssembly:
error CS0012: The type 'ParentClass' is defined in an assembly that is not referenced.
Вызов конструктора собирается, вызов метода — нет. Потому что на первого компилятору достаточно пройти список конструкторов класса, а для второго — все методы, включая унаследованные, чтобы выбрать правильный overload.
Что интересно, преобразование к интерфейсу тоже не собирается, хотя теоретически если child-class его реализует, то parent смотреть не надо.
Здравствуйте, Quebecois, Вы писали:
Q>Т.е. на уровне метаданных достаточно вещей, вытянутых из ChildAssembly.
Это ты какие-то странные вещи придумываешь. Нельзя использовать производный класс, не имея метаданных базового.
Q>Я не говорю, что это хорошая user practice. Это просто пример того, что сейчас работает, и сломалось бы при добавлении наследования конструкторов.
Меняешь публичный интерфейс — ломается, не меняешь — не ломается. Добавление наследования конструкторов вообще ничего бы не изменило в этом отношении. Ты высасываешь проблемы из пальца.
Ад пуст, все бесы здесь.
Re[2]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
C>есть внятные объяснения?
Но зачем он нужен?
Наследование же нужно для диспетчеризации (выбора метода на основании типа объекта).
Пока нет объекта какой смысл в наследовании?
Более того, клиенты использующие конструкторы и использующие методы самого объекта обычно разные. Конструируют объекты обычно фабрики и DI контейнеры.
И там явно указывается объект какого типа и как сконструировать.
Ну и логически размышляя, если у объектов одинаковые api (т.к. наследование) и одинаковые конструкторы, следовательно у них одинаковые зависимости и следовательно они не отличатся! Либо реализуют паттерн стратегия.
Пока не могу себе представить где бы мне понадобилось наследование классов стратегий с наследованием конструкторов.
Вот даже гипотетически пусть есть такой код:
var someObject = new BaseClass(4, "some string");
var otherObject = new DerivedClass(4, "some string");
Как наследование конструкторов упростит мой код? Мне же все равно придется писать явно тип наследуемого класса в коде.
А что делать если я не хочу наследование констуркторов? Мне как-то в наследнике придется помечать конструкторы которые нужно "отключить"?
var someObject = new BaseClass(4, "some string");
var ottherObejct = new LoggerDecoratedObject(someObject);
я бы вот точно не хотел что бы у LoggerDecoratedObject были конструкторы из BaseClass.
Здравствуйте, Quebecois, Вы писали:
Q>Оно не соберется без ссылки UserAssembly -> ParentAssembly: Q>
error CS0012: The type 'ParentClass' is defined in an assembly that is not referenced.
Q>Вызов конструктора собирается, вызов метода — нет. Потому что на первого компилятору достаточно пройти список конструкторов класса, а для второго — все методы, включая унаследованные, чтобы выбрать правильный overload. Q>Что интересно, преобразование к интерфейсу тоже не собирается, хотя теоретически если child-class его реализует, то parent смотреть не надо.
А вы как собираетесь определять, что именно было указано в референсах?
Просто в метаданных проекта ссылки на Parent нету — там только ссылка на Child. Ссылка на Parent подтягивается инфраструктурой MSBuild неявно.
В метаданных результирующей сборки ссылка на Parent может быть, а может и не быть — в зависимости от того, во что отрезолвился символ Foo.
В какой момент и как вы предлагаете разработчику определять, что при пересборке Parent можно не пересобирать User?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, xpalex, Вы писали:
X>Пока нет объекта какой смысл в наследовании?
Никогда не видел такое?
public MyException()
{
}
public MyException(string? message) : base(message)
{
}
public MyException(string? message, Exception? innerException) : base(message, innerException)
{
}
...
X>Конструируют объекты обычно фабрики и DI контейнеры.
Обычно? Страшно даже смотреть на твой код.
X>Ну и логически размышляя, если у объектов одинаковые api (т.к. наследование) и одинаковые конструкторы, следовательно у них одинаковые зависимости и следовательно они не отличатся!
Л — Логика.
Ну поздравляю, ты только что доказал, что наследование вообще не нужно.
Серьезно, ты вообще не знаешь как работает наследование что ли?
Ад пуст, все бесы здесь.
Re[3]: почему в C# до сих пор нет наследования конструкторов?
Тут сразу несколько впросов появляется. Я понимаю когда в System.Exception предоставляют три варианта конструирования объекта. Но зачем их все нужно протаскивать в кастомный тип?
Для оберточного исключения, когда мы прячем сбой в кишках и экспортируем наружу только тип исключения своей библиотеки, достаточно третьей формы.
Если же вы пишите логику на исключениях, то вам будет достаточно первой или второй формы. Но вот что бы нужно было больше одной... Это какой-то карго культ — "сделать как в системной библиотеке"...
X>>Конструируют объекты обычно фабрики и DI контейнеры. C>Обычно? Страшно даже смотреть на твой код.
90% new за пределами фабрик и контейнеров это конструирование DTO. Вы используете наследование в data-классах? Я их всегда больше как tuple рассматривал, а не как полноценные объекты и типы.
X>>Ну и логически размышляя, если у объектов одинаковые api (т.к. наследование) и одинаковые конструкторы, следовательно у них одинаковые зависимости и следовательно они не отличатся!
C>Л — Логика. C>Ну поздравляю, ты только что доказал, что наследование вообще не нужно. C>Серьезно, ты вообще не знаешь как работает наследование что ли?
А оно как-то само работает? Это просто механизм для чьей-то работы с однородными объектами.
Я понимаю, когда C++-ники используют наследование для всего подряд, в том числе и для избавления от дублирования кода. Т.е. когда явного отношения 'is-a' между типами нет, но классы содержат одинаковый код.
Но там это наследие времен когда еще не было лямбд. И попытка в zero-cost абстракции.
В C# я не вижу в этом смысла. Композиция и лямбды решают подобные задачи гораздо легче и понятнее.
Re[3]: почему в C# до сих пор нет наследования конструкторов?
Видел, но редко. Обычно MyException кидается в конкретной ситуации, и содержит какие-то специфичные для конкретного типа исключения параметры. Примерно так:
public class MyException: Exception
{
public int Foo { get; init;}
public string Bar { get; init;}
public MyException(int foo, string bar): base($"Invalid operation with {bar} while foo was equal to {foo}")=> (Foo, Bar) = (foo, bar);
}
Возможность бросить MyException без инициализации Foo и Bar нафиг не упала.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sinclair, Вы писали:
S>Обычно MyException кидается в конкретной ситуации, и содержит какие-то специфичные для конкретного типа исключения параметры.
Не говори за всех.
S>Возможность бросить MyException без инициализации Foo и Bar нафиг не упала.
Никто тебе не запрещает.
Ад пуст, все бесы здесь.
Re[4]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, xpalex, Вы писали:
X>Для оберточного исключения, когда мы прячем сбой в кишках и экспортируем наружу только тип исключения своей библиотеки, достаточно третьей формы.
Одна — это уже boilerplate. То есть, больше чем нужно.
X>90% new за пределами фабрик и контейнеров это конструирование DTO. Вы используете наследование в data-классах?
data-класс или DTO? Это не одно и то же.
X>А оно как-то само работает? Это просто механизм для чьей-то работы с однородными объектами.
Ты не ответил на вопрос. Ты сделал заявление, что "если у объектов одинаковые api (т.к. наследование) и одинаковые конструкторы, следовательно у них одинаковые зависимости и следовательно они не отличатся".
Про добавление данных и методов у классов-наследников, выходит, ты никогда не слышал?
Ад пуст, все бесы здесь.
Re: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sinclair, Вы писали:
S>А можно поподробнее объяснить, что имеется в виду? S>Какой сценарий использования предполагается?
Скорее всего необходимость явно переобъявлять не parameterless ктор. Дуристика, по большому счету. Но если наследованием не увлекаться, то не особо то и мешает.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[2]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
C>Никогда не видел такое?
И, объясните уже — какую задачу вы хотите решить? В чем проблема с явным определением конструкторов, и вызовом базовых, там где необходимо?
Re[3]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
НС>>Забей на наследование вообще, тогда и проблем с кторами не будет. C>Ага, будут другие.
Тебе за решение проблем деньги как раз и платят. Наследование в том виде, в котором оно реализовано в мейнстрим ОО языках — большой клубок проблем, и кторный бойлерплейт далеко не самая неприятная из них. Если наследование не использовать — проблем будет меньше.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[4]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
C>есть внятные объяснения?
Если тебе так нужно, то есть SG. Настрой атрибуты и автоматом пропишутся конструкторы с :base()
и солнце б утром не вставало, когда бы не было меня
Re[2]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
X>>Для оберточного исключения, когда мы прячем сбой в кишках и экспортируем наружу только тип исключения своей библиотеки, достаточно третьей формы.
C>Одна — это уже boilerplate. То есть, больше чем нужно.
Хм. т.е. писать код код что бы удалить два других проще?
C>Ты не ответил на вопрос. Ты сделал заявление, что "если у объектов одинаковые api (т.к. наследование) и одинаковые конструкторы, следовательно у них одинаковые зависимости и следовательно они не отличатся".
Цепочка рассуждений достоаточно простая:
одинаковые конструкторы => одинаковый набор исходных данных.
одинаковый набор исходных данных, при эквивалентном api => одинаковый результат.
Другое дело, алгоритмы внутри могут отличаться, но тогда отношение между классами скорее sibling, чем hierarchy.
Но если мы используем глобальные зависимости или нарушаем LSP — то, конечно, утверждение неверно.
C>Про добавление данных и методов у классов-наследников, выходит, ты никогда не слышал?
И чем наполняются новые поля, если конструкторы не поменялись? Или вы адепт сеттер-инициализации?
Base object1 = new Base(...);
Base object2 = new Derived(...);
(object2 as Derived).callNewShinyMethod(); // мы точно сейчас говорим про наследование и ООП?
Еще раз повторюсь, использование наследования только для переиспользования кода мне кажетя избыточным. Мне достаточно композиции. Но это мой вкус.
Re[6]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
X>>Хм. т.е. писать код код что бы удалить два других проще? C>А тебе позарез нужно их удалить?
Оставлять конструкторы, которые создают неконсистентный объект. Ну так себе предложение...
X>>И чем наполняются новые поля, если конструкторы не поменялись? C>Ты вообще в курсе, что наследование обычно подразумевает возможность добавления, в том числе и конструкторов?
И как можно добавить конструктор так, что бы конструкторы остались одинаковыми?
Или ты мне просто про наследование расказываешь безотносительно моего утверждения про идентичность конструкторов?
Я про это и говорил с самого начала, что наследование без изменения конструкторов этакий code-smell.
C>Ну и зачем тогда ты свой вкус мне навязываешь?
Кто ж навязывает?
Я просто хотел увидеть хоть одну внятную причину по которой может понадобиться наследование конструкторов.
Re[5]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
C>А тебе позарез нужно их удалить?
Если они нарушают инварианты нового класса — да, нужно.
C>Ты вообще в курсе, что наследование обычно подразумевает возможность добавления, в том числе и конструкторов? Обычно к конструкторам это не относится. Можно посмотреть на язык, в котором конструкторы наследуются по умолчанию?
Тут, на самом деле, есть некий философский момент, связанный c механикой порождения экземпляров. С одной точки зрения, конструктор в дотнете — это не конструктор, а "метод инициализации", т.к. к моменту его вызова объект с т.з. рантайма уже "сконструирован". В частности — память подо всё, что надо, выделена и очищена; VMT и таблица интерфейсов полностью построены.
С другой точки зрения, конструктор — это вшитая в язык реализация паттерна "фабрика". Как если бы у нас был параллельный нашему классу объект-синглтон, который оборудован всеми статик методами и конструкторами нашего класса.
Наиболее полно (из известных мне) эта модель была реализована в Delphi, где статик методы и конструкторы могли быть виртуальными.
В новомодной версии шарпа появились static abstract members в интерфейсах — это примерно оно, хоть и в менее развитом виде.
И вот с такой точки зрения наследование конструкторов выглядит логично: у нас есть BaseFactory с набором методов, которые превращают некие аргументы в экземпляры BaseClass.
А есть DerivedFactory, которая реализует совместимый с BaseFactory набор методов: то есть ковариантные return types (она же порождает экземпляры DerivedClass), плюс, быть может, контравариантные типы аргументов.
Насколько этот паттерн часто встречается в практике, чтобы заслуживать нативную поддержку в языке — .
C>Тоже вариант.
Тогда вам хватит одного конструктора — который без параметров. А вся остальная роскошь — через Object и Collection initializers.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, xpalex, Вы писали:
X>Оставлять конструкторы, которые создают неконсистентный объект. Ну так себе предложение...
Кто сказал, что он неконсистентный? Про опциональные данные никогда не слышал?
X>И как можно добавить конструктор так, что бы конструкторы остались одинаковыми?
1) Кто сказал, что они все должны остаться одинаковыми?
2) Ты понимаешь чем "добавить" отличается от "изменить", я надеюсь?
X>Кто ж навязывает?
Ты.
Ад пуст, все бесы здесь.
Re[9]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали: C>Ключевое слово — если.
Было бы интересно посмотреть на живые, не синтетические примеры. C>Именно.
Может, это не просто так? S>>Тогда вам хватит одного конструктора — который без параметров. А вся остальная роскошь — через Object и Collection initializers. C>Да и вообще можно наверно обойтись без конструкторов с аргументами, если очень постараться?
Ну, если вам нравятся object и collection initializers — почему нет?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, xpalex, Вы писали:
X>Я про это и говорил с самого начала, что наследование без изменения конструкторов этакий code-smell.
т.е. если я унаследуюсь от KeyedCollection,
то мне обязательно нужно вручную продублировать все три конструктора, которые просто вызовут конструкторы базового класса и тогда код будет нормальный, а если конструкторы сгенерируются автоматически, то код — плохой?
Или нельзя конструкторы так дублировать и обязательно нужно что-то своё придумать?
Re[11]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
X>>И как можно добавить конструктор так, что бы конструкторы остались одинаковыми?
C>1) Кто сказал, что они все должны остаться одинаковыми? C>2) Ты понимаешь чем "добавить" отличается от "изменить", я надеюсь?
"добавить" элемент в множество == "изменить" множество. Но боюсь для тебя это высшая математика.
Дальше не интересно.
Re[9]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, karbofos42, Вы писали:
K>т.е. если я унаследуюсь от KeyedCollection, K>то мне обязательно нужно вручную продублировать все три конструктора, которые просто вызовут конструкторы базового класса и тогда код будет нормальный, а если конструкторы сгенерируются автоматически, то код — плохой? K>Или нельзя конструкторы так дублировать и обязательно нужно что-то своё придумать?
Да где ж я говорил про то, что надо поменять все?
Я говорил, что если конструкторы (== множество конструкторов) не поменялись, то вероятнее всего ваш класс делает то же самое, что и базовый
либо является стратегией (т.е. делает то же самое, но не так же).
В случае KeyedCollection — т.к. класс абстрактный, реализующий паттерн "шаблонный метод", то метод GetKeyForItem я бы считал за неявный параметр. И вы обязаны передать эту зависимость в вашем производном классе.
Можно ли утверждать, что инстансы вашего производного класса ведут себя не так, как инстансы KeyedCollection? Вряд-ли, т.к. последних не существует.
Re[10]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, xpalex, Вы писали:
X>В случае KeyedCollection — т.к. класс абстрактный, реализующий паттерн "шаблонный метод", то метод GetKeyForItem я бы считал за неявный параметр. И вы обязаны передать эту зависимость в вашем производном классе.
т.е. я не могу сделать SimpleOrder как в примере?
Обязательно нужно сделать наследника универсальным классом, выдумывать ему новые конструкторы, в которые принимать делегат и перегружать GetKeyForItem, чтобы он дёргал этот делегат?
Или как там зависимость передавать нужно?
Re[9]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, karbofos42, Вы писали: K>т.е. если я унаследуюсь от KeyedCollection, K>то мне обязательно нужно вручную продублировать все три конструктора,
Эмм, а, собственно, зачем?
Всё зависит от сценария использования. Покажите мне вашего наследника KeyedCollection, вместе со сценариями использования.
Вот, например, что мы видим в стандартной библиотеке: KeyedByTypeCollection:
KeyedByTypeCollection<TItem>()
KeyedByTypeCollection<TItem>(IEnumerable<TItem>)
LocalizedEntryCollection<T>:
LocalizedEntryCollection<T>()
MessageHeaderDescriptionCollection:
--
MessagePartDescriptionCollection:
--
...
SrgsRulesCollection:
SrgsRulesCollection()
RuleConditionCollection:
RuleConditionCollection()
...
Внезапно оказывается, что наследники KeyedCollection никогда не дублируют никакие из базовых конструкторов, кроме дефолтного (да и тот — не всегда).
Почему вы думаете, что вам, в отличие от авторов фреймворка, придётся обязательно дублировать все три конструктора?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, karbofos42, Вы писали:
K>т.е. я не могу сделать SimpleOrder как в примере? K>Обязательно нужно сделать наследника универсальным классом, выдумывать ему новые конструкторы, в которые принимать делегат и перегружать GetKeyForItem, чтобы он дёргал этот делегат? K>Или как там зависимость передавать нужно?
В других язывках это можно делать, например, так:
var simpleOrder = new KeyedCollection<int, OrderItem>(null, 0) {
@Override
protected int GetKeyForItem(OrderItem item) {
return item.PartNumber;
}
}
В c# нужно явно переопределять в новом классе.
Кстати, в примере с SimpleOrder оставляют один конструктор вместо трех.
Вопросы в другом:
1. Считаете ли вы, что утверждение
делает то же самое
описывает отношение между SimpleOrder и KeyedCollection или нет?
2. Применительно ли такое сравнение между абстрактными и неабстрактными классами?
Если ответы 1. нет, 2. да, то тогда вы нашли опровержение моего утверждения и можете со спокойной душой его игнорировать, как фальшивое.
Re[10]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sinclair, Вы писали:
S>Почему вы думаете, что вам, в отличие от авторов фреймворка, придётся обязательно дублировать все три конструктора?
Ну, привычка у меня такая: давать максимум доступного функционала на всякий случай.
Сразу не делаешь конструктор — в итоге появляется неоптимальный код или приходится потом возвращаться и дописывать.
Re[12]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, xpalex, Вы писали:
X>В c# нужно явно переопределять в новом классе. X>Кстати, в примере с SimpleOrder оставляют один конструктор вместо трех.
Так и в чём проблема было добавить возможность написать в SimpleOrder как в C++ что-то типа:
using SimpleOrder::base;
и получить унаследованные все 3 конструктора без необходимости ручной работы?
X>1. Считаете ли вы, что утверждение
делает то же самое
описывает отношение между SimpleOrder и KeyedCollection или нет?
классы делают одно и то же, дополнительного состояния даже никакого не добавилось в SimpleOrder.
X>2. Применительно ли такое сравнение между абстрактными и неабстрактными классами?
Каждый класс должен делать условно что-то одно. Абстрактные классы и их наследники априори делают одно и то же,
т.к. созданы для одних и тех же целей, имеют общий интерфейс и для клиентского кода не должно быть между ними разницы.
X>Если ответы 1. нет, 2. да, то тогда вы нашли опровержение моего утверждения и можете со спокойной душой его игнорировать, как фальшивое.
Я нахожу демагогию, которая не отвечает на исходный вопрос темы.
Re[11]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, karbofos42, Вы писали:
K>Ну, привычка у меня такая: давать максимум доступного функционала на всякий случай.
Бросайте её. YAGNI. K>Сразу не делаешь конструктор — в итоге появляется неоптимальный код или приходится потом возвращаться и дописывать.
Потом возвращаться и дописывать гораздо эффективнее:
— это приходится делать не всегда
— когда приходится это делать, у вас уже есть понимание предполагаемого сценария использования, поэтому вы можете сделать более оптимальный код
Ну, и я всё ещё не увидел никакого примера, в котором вам бы реально потребовалось выставлять наружу в вашем наследнике KeyedCollection конструктор с IEqualityComparer, а без этого у вас бы получился неоптимальный код.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: почему в C# до сих пор нет наследования конструкторов?
НС>Тебе за решение проблем деньги как раз и платят. Наследование в том виде, в котором оно реализовано в мейнстрим ОО языках — большой клубок проблем, и кторный бойлерплейт далеко не самая неприятная из них. Если наследование не использовать — проблем будет меньше.
Что не так с наследованием в с#?
Кодом людям нужно помогать!
Re[3]: почему в C# до сих пор нет наследования конструкторов
Так что не так и что предлагается улучшить?
Т.е. неохота всей этой писанины, если будет вызываться только один контсруктор, соотв. только его и наследуем?
Так или не так?
Здравствуйте, xpalex, Вы писали:
X>"добавить" элемент в множество == "изменить" множество. Но боюсь для тебя это высшая математика. X>Дальше не интересно.
Ты по прежнему порешь чушь, вот и все. Кто сказал, что добавлять новые конструкторы или изменять некоторые из них нельзя?
Ад пуст, все бесы здесь.
Re[4]: почему в C# до сих пор нет наследования конструкторов
Здравствуйте, Codealot, Вы писали:
S>>Т.е. неохота всей этой писанины, если будет вызываться только один контсруктор, соотв. только его и наследуем? C>А если не только один?
Не понятно, чем не устраивает что есть сейчас. Приведите конкретный пример, мол есть сейчас вот это,
хотелось бы так-то и так-то.
Кодом людям нужно помогать!
Re[12]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sinclair, Вы писали:
S>Потом возвращаться и дописывать гораздо эффективнее: S>- это приходится делать не всегда S>- когда приходится это делать, у вас уже есть понимание предполагаемого сценария использования, поэтому вы можете сделать более оптимальный код
Дописать это сейчас — 5 минут нудной, рутинной работы, т.к. я в контексте и знаю как всё работает.
Если не понадобится — я потерял 5 минут времени, бывает.
Если же понадобится через полгода, то я потрачу полчаса, а то и несколько часов.
Потому что, сначала нужно разобраться во всех этих наследованиях, найти тот класс, где есть нужный конструктор, потом по всей иерархии его пробросить.
Это ещё при условии, что кто-то вообще задумается, что возможно где-то в недрах есть нужный конструктор, а не надстроит что-то сверху через фабрики или ещё какие-нибудь отличные паттерны.
S>Ну, и я всё ещё не увидел никакого примера, в котором вам бы реально потребовалось выставлять наружу в вашем наследнике KeyedCollection конструктор с IEqualityComparer, а без этого у вас бы получился неоптимальный код.
Так с исключениями вполне нормальный пример.
Когда начинаешь библиотечные классы делать и заводишь свои типы исключений — постоянно эта писанина пустых конструкторов.
Либо сразу ленишься писать конструктор с innerException, а потом он внезапно становится нужен и возвращаешься дописывать.
Если это отдельная библиотека, то будет дополнительное веселье ради этого пересобирать nuget-пакет.
Не скажу, что прямо киллер-фича и без этого нельзя жить, но вроде нет проблем это добавить ни идеологически, ни технически.
Re[13]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, karbofos42, Вы писали: K>Дописать это сейчас — 5 минут нудной, рутинной работы, т.к. я в контексте и знаю как всё работает. K>Если не понадобится — я потерял 5 минут времени, бывает.
Помимо потери 5 минут времени, вы пишете код, который вы не знаете для чего нужен. У вас нет ни одной точки, в которой для вашей коллекции вызывается конструктор с нестандартным компарером.
Через полгода, когда вы поняли, что для вашей коллекции важно использовать какой-то конкретный компарер, у вас уже есть неизвестное количество кода, заточившегося под этот конструктор.
Вам придётся потратить часы и дни на исследоание этих зависимостей и проверку того, что убирание конструктора не сломает обратную совместимость.
Убирать код всегда дороже, чем его писать.
K>Если же понадобится через полгода, то я потрачу полчаса, а то и несколько часов.
На что вы потратите полчаса? На нажатие Ctrl+. и Generate method? Очень в этом сомневаюсь. K>Потому что, сначала нужно разобраться во всех этих наследованиях, найти тот класс, где есть нужный конструктор, потом по всей иерархии его пробросить.
Звучит пугающе, но тут помог бы реальный пример. Потому, что на такие вещи, когда call site уже известен, уходят буквально секунды — go to definition, и поехали.
Добавить пустой конструктор — дело нескольких секунд, неважно сегодня или через полгода.
Главное — что добавление конструктора никакую обратную совместимость не ломает. Поэтому это дёшево.
Если у вас там цепочка наследования — ну умножим мы несколько секунд на 5. Да хоть на 10 — всё это совершенно тривиальные действия, большую часть которых выполняет IDE.
K>Это ещё при условии, что кто-то вообще задумается, что возможно где-то в недрах есть нужный конструктор, а не надстроит что-то сверху через фабрики или ещё какие-нибудь отличные паттерны.
Вот этот момент категорически непонятен. Какие ещё фабрики? Вы привели пример KeyedCollection — ну, покажите мне, как обойти отсутствие конструктора с IEqualityComparer при помощи фабрики.
K>Так с исключениями вполне нормальный пример.
Ок, то есть ваш пример с KeyedCollection был просто так? K>Когда начинаешь библиотечные классы делать и заводишь свои типы исключений — постоянно эта писанина пустых конструкторов.
Да откуда она берётся-то???? Когда я пишу библиотечные классы и мне зачем-то надобятся мои собственные классы исключений, я никогда не пишу пустых конструкторов.
Весь смысл своих типов исключений — это возможность сконструировать их так, как удобно мне, а не фреймворку. K>Либо сразу ленишься писать конструктор с innerException, а потом он внезапно становится нужен и возвращаешься дописывать.
Во-первых, если он "внезапно" становится нужным, то у вас что-то не так с проектированием. Вы же знаете, в каких случаях собираетесь бросать ваш Exception? Значит, знаете и потребность в innerException или в его отсутствии.
У вас и код, который его ловит, наверное будет заточен под наличие либо отсутствие innerException. Ну, а если всё же требования изменились на ходу — ну, ок, для такого редкого случая не грех и конструктор добавить, и пакет пересобрать.
K>Если это отдельная библиотека, то будет дополнительное веселье ради этого пересобирать nuget-пакет. K>Не скажу, что прямо киллер-фича и без этого нельзя жить, но вроде нет проблем это добавить ни идеологически, ни технически.
Совершенно верно. И это можно сделать без изменения языка.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: почему в C# до сих пор нет наследования конструкторов
Здравствуйте, Sharov, Вы писали:
S>Не понятно, чем не устраивает что есть сейчас. Приведите конкретный пример, мол есть сейчас вот это, S>хотелось бы так-то и так-то.
Любой конструктор с параметрами, где сейчас нужно делать копию всех аргументов и писать base(). Надеюсь, хотя бы зачем нужен base() тебе понятно?
Ад пуст, все бесы здесь.
Re[5]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
НС>>Тебе за решение проблем деньги как раз и платят. Наследование в том виде, в котором оно реализовано в мейнстрим ОО языках — большой клубок проблем, и кторный бойлерплейт далеко не самая неприятная из них. Если наследование не использовать — проблем будет меньше. S>Что не так с наследованием в с#?
Слишком сильная связность между предком и наследником, слишком низкая гибкость такой связи, неразрываемая и не настраиваемая связь между наследованием контракта и наследованием реализации. Пропустил вечный флейм про то, кто у кого наследник, прямоугольник у квадрата или квадрат у прямоугольника?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[6]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Что не так с наследованием в с#? НС>Слишком сильная связность между предком и наследником, слишком низкая гибкость такой связи, неразрываемая и не настраиваемая связь между наследованием контракта и наследованием реализации.
Почему же неразрываемая и не настраиваемая -- а паттерн декоратор на что? + ключевое слово new для разрыва
реализации.
Кодом людям нужно помогать!
Re[14]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sinclair, Вы писали:
S>Помимо потери 5 минут времени, вы пишете код, который вы не знаете для чего нужен.
Ну, в Майкрософте в абстрактном классе написали этот конструктор и внутри даже запилили поддержку кастомных компареров, хотя проще было делать только для дефолтного.
А я конечно для себя не могу конструктор написать, потому что они вот знали зачем он нужен, а я не знаю.
S>У вас нет ни одной точки, в которой для вашей коллекции вызывается конструктор с нестандартным компарером. S>Через полгода, когда вы поняли, что для вашей коллекции важно использовать какой-то конкретный компарер, у вас уже есть неизвестное количество кода, заточившегося под этот конструктор.
Так у меня нет ни одной точки или у меня неизвестное количество кода?
Если я не использую конструктор с кастомным комперером, а сегодня он мне понадобился — я в нужном месте добавил вызов и всё.
Если таки использую — значит он подавно был уже мне нужен и писал не зря.
S>Убирать код всегда дороже, чем его писать.
Зачем его убирать? Он есть, хлеба не просит.
А вот если класс был завязан на дефолтный компарер, а потом вдруг понадобился кастомный, вот тут может быть веселье с добавлением кода.
Ищи все проверки объектов и меняй их на вызов компарера.
S>Главное — что добавление конструктора никакую обратную совместимость не ломает. Поэтому это дёшево.
А какую совместимость ломает неиспользуемый конструктор?
Если был конструктор, принимающий IEnumerable<T>, а я добавлю конструктор, принимающий ICollection<T>, то там точно совместимость не сломается?
S>Вот этот момент категорически непонятен. Какие ещё фабрики? Вы привели пример KeyedCollection — ну, покажите мне, как обойти отсутствие конструктора с IEqualityComparer при помощи фабрики.
Создаём наследника от наследника KeyedCollection. Опять перегружаем в нём метод GetKeyForItem, чтобы он возвращал наследника ключа, для которого прописано правильное сравнение по умолчанию.
т.к. мы пишем по паттернам и всему такому, то вызов конструктора выносим в фабрику, которая будет возвращать либо исходного наследника с одним сравнением, либо его потомка — с другим.
К чему вот эти поиски реального примера на форуме?
Реальный код в большинстве своём коммерческий и принадлежит работодателю.
Чтобы показать масштаб трагедии — там нужно целый проект вывалить, а то будет опять, что пару конструктором нормально и вручную написать.
Да и там в итоге будет, что так не нужно писать, нужно всё отрефакторить, переделать, потратить неделю времени на то, чтобы обойти это.
Хотя исходный вопрос был в наследовании конструкторов.
Почему наследование методов — это нормально, а конструкторы — это плохо и неправильно, я так и не понял.
Re[7]: почему в C# до сих пор нет наследования конструкторов
Здравствуйте, Codealot, Вы писали:
S>>Не понятно, чем не устраивает что есть сейчас. Приведите конкретный пример, мол есть сейчас вот это, S>>хотелось бы так-то и так-то. C>Любой конструктор с параметрами, где сейчас нужно делать копию всех аргументов и писать base(). Надеюсь, хотя бы зачем нужен base() тебе понятно?
Зачем сразу всех -- тех которые нужны, а для остальных значения по умолчанию.
В любом случае, про гитхаб слышали? Заводили там когда-нибудь issue для бага или улучшения?
Так вот, там надо сначала описать что есть, что хотелось бы и т.д., а не экивоками и намеками общаться.
Кодом людям нужно помогать!
Re[8]: почему в C# до сих пор нет наследования конструкторов
Здравствуйте, Sharov, Вы писали:
S>Зачем сразу всех -- тех которые нужны, а для остальных значения по умолчанию.
А зачем? Тебя же не напрягает, что класс наследует все методы и данные базового?
S>В любом случае, про гитхаб слышали? Заводили там когда-нибудь issue для бага или улучшения?
Читал. Там дуб. Непрошибаемый. По каким принципам они выбирают что делать — видимо, исключительно по желанию чьей-то левой пятки. Потому что даже такая элементарщину, как унифицировать интерфейс Array и List, они решили не делать. Даже когда начали делать с нуля корку.
S>Так вот, там надо сначала описать что есть, что хотелось бы и т.д., а не экивоками и намеками общаться.
Мне просто интересна мотивация, вдруг кто знает разумные аргументы против. Пока ни одного не видел.
Ад пуст, все бесы здесь.
Re[4]: почему в C# до сих пор нет наследования конструкторов
S>Так что не так и что предлагается улучшить? S>Т.е. неохота всей этой писанины, если будет вызываться только один контсруктор, соотв. только его и наследуем? S>Так или не так?
Самое забавное, что эта реализация тоже не ок. Если вдруг появится необходимость в дополнительной инициализации (например добавится новое поле или еще что-то), то придется дублировать код инициализации во всех трех конструкторах.
Идиоматичней было бы так:
public MyException() : this(null, null)
{
}
public MyException(string? message) : this(message, null)
{
}
public MyException(string? message, Exception? innerException) : base(message, innerException)
{
// any additional init goes here ...
Console.WriteLine("MyException was created at {0}", DateTime.UtcNow);
}
...
Но это рушит чью-то картину необходимости и тем более корректности автоматической генерации конструкторов.
Здравствуйте, karbofos42, Вы писали:
K>Ну, привычка у меня такая: давать максимум доступного функционала на всякий случай.
Плохая привычка.
K>Сразу не делаешь конструктор — в итоге появляется неоптимальный код или приходится потом возвращаться и дописывать.
Возвращаться и дописывать — это нормально, рефакторинг — наше все.
Намного лучше, чем сделать слишком универсальный, а потому сложный и неудобный код, а эту универсальность потом не использовать.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[11]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Почему же неразрываемая и не настраиваемая -- а паттерн декоратор на что?
НС>А при чем тут наследование?
Декоратор это один из методов реализации подтипа. Сохраняем все основные операции, только немного модифицируем поведение. Тип — это семейство объектов со схожим поведеним.
Стратегия про то же — реализация подтипа.
Re[9]: почему в C# до сих пор нет наследования конструкторов
Здравствуйте, Codealot, Вы писали:
S>>В любом случае, про гитхаб слышали? Заводили там когда-нибудь issue для бага или улучшения?
C>Читал. Там дуб. Непрошибаемый. По каким принципам они выбирают что делать — видимо, исключительно по желанию чьей-то левой пятки. Потому что даже такая элементарщину, как унифицировать интерфейс Array и List, они решили не делать. Даже когда начали делать с нуля корку.
Это надо было делать во фремворке 1.0. Дальше это обросло чудовищным количеством кода. И если унифицировать интерфейс Array и List это может дать неопределенное количество поломок с обратной совместимостью.
Re[7]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
НС>>Слишком сильная связность между предком и наследником, слишком низкая гибкость такой связи, неразрываемая и не настраиваемая связь между наследованием контракта и наследованием реализации.
S>Почему же неразрываемая и не настраиваемая -- а паттерн декоратор на что?
Паттерн декоратор это библиотечный способ решить проблему с наследованием, как и стратегия
В ООП класс это одновременно тип и модуль. Экземпляр он тоже модуль в т.ч. Вот такая двойственность неискоренима.
С наследованием всё хорошо, если ты используешь классы только как типы, а наследование только как subtype. И точно так же всё хорошо, если используешь классы только модули, а наследование — только как расширение модуля.
Штука в том, что таких задач крайне мало. А раз так, то у тебя всегда в той или иной степени смешиваются тип и модуль.
Интерфейс это ровно та же хрень — и класс и модуль. Соответсвенно, отсюда ясно, что расширяя интерфейс-тип как модуль, мы вносим ровно тот же хаос, что и в обычном наследовании реализации
Потому что в общем случае сконструировать обьект-потомок используя конструктор родителя невозможно? Родитель не знает что в потомка накидали, он вообще про его наличие ничего не знает.
По-моему хорошая причина.
Re[9]: почему в C# до сих пор нет наследования конструкторов
Здравствуйте, Sinclair, Вы писали:
S>У вас нет ни одной точки, в которой для вашей коллекции вызывается конструктор с нестандартным компарером. S>Через полгода, когда вы поняли, что для вашей коллекции важно использовать какой-то конкретный компарер, у вас уже есть неизвестное количество кода, заточившегося под этот конструктор.
Ты уж определись — или трусы, или крестик.
Ад пуст, все бесы здесь.
Re[12]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Teolog, Вы писали:
T>Потому что в общем случае сконструировать обьект-потомок используя конструктор родителя невозможно? Родитель не знает что в потомка накидали, он вообще про его наличие ничего не знает.
Может тогда и readonly не нужен, раз его нельзя использовать для всех значений во всех мыслимых случаях?
T>По-моему хорошая причина.
Идиотская.
Ад пуст, все бесы здесь.
Re[10]: почему в C# до сих пор нет наследования конструкторов
Здравствуйте, Pauel, Вы писали:
P>Это надо было делать во фремворке 1.0. Дальше это обросло чудовищным количеством кода. И если унифицировать интерфейс Array и List это может дать неопределенное количество поломок с обратной совместимостью.
Просто добавить методы с одинаковыми сигнатурами, где их еще нет.
.Sort() вдобавок к статическому Array.Sort() и так далее.
Ад пуст, все бесы здесь.
Re[10]: почему в C# до сих пор нет наследования конструкторов
Здравствуйте, 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>Но это рушит чью-то картину необходимости и тем более корректности автоматической генерации конструкторов.
На самом деле нет
Ад пуст, все бесы здесь.
Re[12]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Плохая привычка.
Ну, тут главное не увлекаться. Я же не пишу на всякий случай километры кода, а небольшие плюшки за 5 минут чего бы не написать?
НС>Возвращаться и дописывать — это нормально, рефакторинг — наше все. НС>Намного лучше, чем сделать слишком универсальный, а потому сложный и неудобный код, а эту универсальность потом не использовать.
Если сделал сразу, то больше вероятность что рефакторинг и доработка не потребуются, а значит не нужно будет лезть в старый проверенный код и что-то там менять, заново тестировать и т.п.
Re[6]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
НС>>Плохая привычка. C>"Я тут подумал и решил, что мне лень это делать, а пользователи пусть сами выкручиваются" — намного хуже.
При чем тут пользователи?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[13]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, karbofos42, Вы писали:
НС>>Плохая привычка. K>Ну, тут главное не увлекаться. Я же не пишу на всякий случай километры кода, а небольшие плюшки за 5 минут чего бы не написать?
Антон вроде понятно объяснил. 5 минут написать, потом 5 дней потерять на поддержке.
НС>>Возвращаться и дописывать — это нормально, рефакторинг — наше все. НС>>Намного лучше, чем сделать слишком универсальный, а потому сложный и неудобный код, а эту универсальность потом не использовать. K>Если сделал сразу, то больше вероятность что рефакторинг и доработка не потребуются
Не надо боятся рефакторинга и воспринимать его как зло. Качество кода, которое достигается регулярным рефакторингом недостижимо никакими другими способами.
K>, а значит не нужно будет лезть в старый проверенный код и что-то там менять
Не бывает. Не бывает чтобы старый код долго жил без накопления техдолга.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[11]: почему в C# до сих пор нет наследования конструкторов
Здравствуйте, Codealot, Вы писали:
НС>>неразрываемая и не настраиваемая связь между наследованием контракта и наследованием реализации. C>Интерфейсы, не слышал?
Интерфейсы это совсем другая история. Интерфейсы это чистая абстракция контракта, поэтому наследование интерфейсов между собой, в отличие от классов, чистое и не порождает никаких скрытых связей.
НС>>Пропустил вечный флейм про то, кто у кого наследник, прямоугольник у квадрата или квадрат у прямоугольника? C>И правильно, потому что проблема высосана из пальца.
Да? Ну расскажи как правильно тогда.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[14]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Интерфейсы это совсем другая история. Интерфейсы это чистая абстракция контракта, поэтому наследование интерфейсов между собой, в отличие от классов, чистое и не порождает никаких скрытых связей.
Нет, не другая. А еще есть абстрактные классы. Не слышал?
НС>Да? Ну расскажи как правильно тогда.
Во первых — задача глупая. Зачем тебе так приспичило сделать отдельный класс для квадрата?
Ад пуст, все бесы здесь.
Re[14]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>5 минут написать, потом 5 дней потерять на поддержке.
Если твой код использует кто-то кроме тебя, то не забывай про время, которое сэкономили пользователи. А то похоже, что тебя волнует только как минимизировать затраты своего времени любой ценой.
Ад пуст, все бесы здесь.
Re[15]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
НС>>Т.е. проблема исключительно в сортировке и ее перфомансе? Или есть еще что то? C>Перформанс тут вообще ни при чем.
Если перфоманс не причем, то контракта IList более чем достаточно чтобы реализовать универсальную сортировку в виде внешней функции.
C>Ты на вопрос в состоянии ответить?
Какой вопрос?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[9]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
НС>>Интерфейсы это совсем другая история. Интерфейсы это чистая абстракция контракта, поэтому наследование интерфейсов между собой, в отличие от классов, чистое и не порождает никаких скрытых связей. C>Нет, не другая.
Другая.
C>А еще есть абстрактные классы. Не слышал?
Есть. И с ними та же проблема, что и с неабстрактными. Если, конечно, абстрактный класс не вырождается до интерфейса.
НС>>Да? Ну расскажи как правильно тогда. C>Во первых — задача глупая.
Задача модельная. И отлично демонстрирует проблему.
C> Зачем тебе так приспичило сделать отдельный класс для квадрата?
Еще раз — задача модельная, для исллюстрации. Не надо копать в сторону требований. Если тебе прям так важна какая то причина — пусть чтобы сэкономить память. Так что от чего наследовать то?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[16]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Проектирование публичного API — это отдельная большая тема. Где, к примеру, есть понятие breking changes.
Можно подумать, ты что-то новое сказал.
Так его ты тоже проектируешь по принципу "чем меньше я сделаю, тем лучше"?
Ад пуст, все бесы здесь.
Re[16]: почему в C# до сих пор нет наследования конструкторо
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Если перфоманс не причем, то контракта IList более чем достаточно чтобы реализовать универсальную сортировку в виде внешней функции.
Навелосипедить всегда можно, но это не изменяет того факта, что разработчики .NET налажали. Точнее, даже сам факт, что нужен велосипед — доказательство того, что они налажали.
НС>Какой вопрос?
У тебя СДВГ? Нужно знать, если тебе нужны reasonable accommodations и какие.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Другая.
А, мамой клянешься?
НС>Есть. И с ними та же проблема, что и с неабстрактными. Если, конечно, абстрактный класс не вырождается до интерфейса.
То есть идея о том, что контракты и реализации можно определить в разных пропорциях в разных классах иерархии, она тебе классово чужда?
НС>Задача модельная. И отлично демонстрирует проблему.
Высосанная из пальца.
НС>Еще раз — задача модельная, для исллюстрации. Не надо копать в сторону требований. Если тебе прям так важна какая то причина — пусть чтобы сэкономить память. Так что от чего наследовать то?
Ну нет, давай конкретные требования. И не забывай о том, что любая добавочная логика тоже сжирает память, которую ты собрался экономить.
Что конкретно ты собрался делать с этими квадратами, сколько их у тебя и зачем?
Ад пуст, все бесы здесь.
Re[8]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Почему же неразрываемая и не настраиваемая -- а паттерн декоратор на что? НС>А при чем тут наследование?
Как причем? Декоратор реализуется в первую очередь посредством наследования, для патчинга
соотв. класса.
S>>+ ключевое слово new для разрыва реализации. НС>Ключевое слово new ничего не разрывает, потому что кастинг к базовому классу его игнорирует.
Разрывает cлишком сильную связность между предком и наследником.
Кодом людям нужно помогать!
Re[8]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Pauel, Вы писали:
S>>Почему же неразрываемая и не настраиваемая -- а паттерн декоратор на что? P>Паттерн декоратор это библиотечный способ решить проблему с наследованием, как и стратегия
Никакой библиотеки для его реализации не надо, только наследование и конструктор с параметром.
Т.е. средствами ЯП.
P>В ООП класс это одновременно тип и модуль. Экземпляр он тоже модуль в т.ч. Вот такая двойственность неискоренима. P>С наследованием всё хорошо, если ты используешь классы только как типы, а наследование только как subtype. И точно так же всё хорошо, если используешь классы только модули, а наследование — только как расширение модуля. P>Штука в том, что таких задач крайне мало. А раз так, то у тебя всегда в той или иной степени смешиваются тип и модуль.
Ничего не понял, если честно.
Кодом людям нужно помогать!
Re[17]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
C>Так его ты тоже проектируешь по принципу "чем меньше я сделаю, тем лучше"?
Я его проектирую по принципу — не делать вещей для которых нет известных use cases. Добавление дополнительных кторов это не breaking change, а вот удаление — да.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[17]: почему в C# до сих пор нет наследования конструкторо
Здравствуйте, Codealot, Вы писали:
НС>>Они его не сэкономят, а потеряют, когда тебе придется свою кучу кторов поменять. C>1) Что конкретно тебе понадобится менять и зачем?
Что угодно. Чем жирнее контракт, тем выше вероятность breaking changes
C>2) А если они будут сами велосипедить все что не сделал ты, то они его сэкономят?
Если будут сами — будет известный и понятный юзкейс, под который можно вменяемо доработать public API. И не факт что это будет именно добавление нового ктора.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[15]: почему в C# до сих пор нет наследования конструкторо
Здравствуйте, Codealot, Вы писали:
НС>>Если перфоманс не причем, то контракта IList более чем достаточно чтобы реализовать универсальную сортировку в виде внешней функции. C>Навелосипедить всегда можно,
Можно не велосипедить, а использовать тот же OrderBy.
НС>>Какой вопрос? C>У тебя СДВГ?
Удачной баньки.
C> Нужно знать, если тебе нужны reasonable accommodations и какие.
Что нужно знать? Опять какие то обрывки смысла.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[9]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>>>Почему же неразрываемая и не настраиваемая -- а паттерн декоратор на что? НС>>А при чем тут наследование? S>Как причем? Декоратор реализуется в первую очередь посредством наследования
Внезапно. Нет, не реализуется в первую очередь он наследованием, там может использоваться наследование если в конкретном языке нет способов поудобнее. А может и не использоваться.
Возьмем, к примеру, пример из википедии. Наследование там только в двух местах, SecurityPackage : BikeAccessories и SportPackage : BikeAccessories. На практике так редко кто делает, вместо этого неабстрактный BikeAccessories содержит список каких нибудь BikeParts обеспечивая тем самым реально динамическое изменение поведения, не зашитое в коде.
S>>>+ ключевое слово new для разрыва реализации. НС>>Ключевое слово new ничего не разрывает, потому что кастинг к базовому классу его игнорирует. S>Разрывает cлишком сильную связность между предком и наследником.
Нет, не разрывает. Это просто синтаксический сахар, ровно то же самое можно получить просто добавлением префикса New к названию метода или чем то аналогичным. В какой то мере разрывает связь не new, а возможность explicit реализации интерфейса, но это уже далеко не классический мейнстримовый ООП и имеет весьма ограниченную область применения.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[11]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
НС>>Другая. C>А, мамой клянешься?
Нет. Я объяснил почему другая.
НС>>Есть. И с ними та же проблема, что и с неабстрактными. Если, конечно, абстрактный класс не вырождается до интерфейса. C>То есть идея о том, что контракты и реализации можно определить в разных пропорциях в разных классах иерархии, она тебе классово чужда?
Нет.
НС>>Задача модельная. И отлично демонстрирует проблему. C>Высосанная из пальца.
Удобно, все что не подходит под теорию объявить высосанным из пальца.
НС>>Еще раз — задача модельная, для исллюстрации. Не надо копать в сторону требований. Если тебе прям так важна какая то причина — пусть чтобы сэкономить память. Так что от чего наследовать то? C>Ну нет, давай конкретные требования. И не забывай о том, что любая добавочная логика тоже сжирает память, которую ты собрался экономить. C>Что конкретно ты собрался делать с этими квадратами, сколько их у тебя и зачем?
Ясно, ответа не будет. ЧТД.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[9]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>Никакой библиотеки для его реализации не надо, только наследование и конструктор с параметром. S>Т.е. средствами ЯП.
Паттерн == библиотечный способ реализации фичи. Встроеный в язык — когда есть фича, например такая
decorator class Widget {
// например каким то способом ограничиваем расширение интерфейса, и гарантируем только изменение поведения публичных методов.
}
P>>В ООП класс это одновременно тип и модуль. Экземпляр он тоже модуль в т.ч. Вот такая двойственность неискоренима. P>>С наследованием всё хорошо, если ты используешь классы только как типы, а наследование только как subtype. И точно так же всё хорошо, если используешь классы только модули, а наследование — только как расширение модуля. P>>Штука в том, что таких задач крайне мало. А раз так, то у тебя всегда в той или иной степени смешиваются тип и модуль.
S>Ничего не понял, если честно.
Ожидаемо. Есть книга Бертрана Мейера Объектно ориентированое проектирование, кажется так. В неё подробно говорится о том, что же такое ооп.
Re[9]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>>>+ ключевое слово new для разрыва реализации. НС>>Ключевое слово new ничего не разрывает, потому что кастинг к базовому классу его игнорирует.
S>Разрывает cлишком сильную связность между предком и наследником.
Разрывает как раз декоратор, стратегия, а не слово new. В некоторых языках никакого new не требуется, просто вызываешь конструктор по имени класса напрямую.
Параметр у new — та самая реализация, где и предок, и наследник прибиты гвоздями друг к другу.
Re[10]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Pauel, Вы писали:
S>>Никакой библиотеки для его реализации не надо, только наследование и конструктор с параметром. S>>Т.е. средствами ЯП. P>Паттерн == библиотечный способ реализации фичи. Встроеный в язык — когда есть фича, например такая P>
P>decorator class Widget {
P> // например каким то способом ограничиваем расширение интерфейса, и гарантируем только изменение поведения публичных методов.
P>}
P>
Для меня библиотечный это именно, что подключать что-то извне, библиотеку какую-нибудь, пусть даже самую базовую.
Тут же ничего такого не надо, а просто несколько строк на самом языке. Ок, это терм. спор.
S>>Ничего не понял, если честно. P>Ожидаемо. Есть книга Бертрана Мейера Объектно ориентированое проектирование, кажется так. В неё подробно говорится о том, что же такое ооп.
Книга эта есть, даже читал большую часть лет 10 назад. Но к чему был тот комментарий "за все хорошее против всего плохо" в контексте
беседы я так и не понял
Кодом людям нужно помогать!
Re[10]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Pauel, Вы писали:
S>>Разрывает cлишком сильную связность между предком и наследником. P>Разрывает как раз декоратор, стратегия, а не слово new. В некоторых языках никакого new не требуется, просто вызываешь конструктор по имени класса напрямую. P>Параметр у new — та самая реализация, где и предок, и наследник прибиты гвоздями друг к другу.
Здравствуйте, Sharov, Вы писали:
S>Для меня библиотечный это именно, что подключать что-то извне, библиотеку какую-нибудь, пусть даже самую базовую. S>Тут же ничего такого не надо, а просто несколько строк на самом языке. Ок, это терм. спор.
Библиотека это совсем необязательно чтото, что надо подключать извне. Это может быть твоя собственная библиотека прямо в соседнем фолдере или даже просто в соседнем файле.
Декораторы обычно являются такой библиотекой — на разные объекты навешиваем комбинации самых разных декораторов.
S>>>Ничего не понял, если честно. P>>Ожидаемо. Есть книга Бертрана Мейера Объектно ориентированое проектирование, кажется так. В неё подробно говорится о том, что же такое ооп.
S>Книга эта есть, даже читал большую часть лет 10 назад. Но к чему был тот комментарий "за все хорошее против всего плохо" в контексте
Я описал проблему, откуда она растет. Класс это два кейса в одном — и тип, и модуль, см эту самую книгу. И наследование, соответственно, тоже два кейса в одном — и уточнение типа, и расширение модуля. Отсюда ясно, что обозначеная проблема в нынешних реализациях ООП неустранима, принципиально.
Вот скажем, если разделить subtype и extends, вроде бы круто, но я вот не сильно уверен, что на таком языке можно будет хоть что нибудь писать, т.к. такое смешение дает чудовищно мощный инструмент.
Re[11]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Как причем? Декоратор реализуется в первую очередь посредством наследования НС>Внезапно. Нет, не реализуется в первую очередь он наследованием, там может использоваться наследование если в конкретном языке нет способов поудобнее. А может и не использоваться.
Внезапно мы про какой ЯП говорим? Соотв. эта аргументация мимо.
НС>Возьмем, к примеру, пример из википедии. Наследование там только в двух местах, SecurityPackage : BikeAccessories и SportPackage : BikeAccessories. На практике так редко кто делает, вместо этого неабстрактный BikeAccessories содержит список каких нибудь BikeParts обеспечивая тем самым реально динамическое изменение поведения, не зашитое в коде.
Судя по тому, что там 2 класса которые мы декорируем, то наследование исп. 100% из 100%. На счет BikeParts хотелось бы
подробностей, поскольку кажется, что именно через спискок BikeParts, обеспечивающий дин. изм. поведения, как раз
мало кто делает. А делают по старинке и классике, т.е. через декоратор.
S>>Разрывает cлишком сильную связность между предком и наследником. НС>Нет, не разрывает. Это просто синтаксический сахар, ровно то же самое можно получить просто добавлением префикса New к названию метода или чем то аналогичным. В какой то мере разрывает связь не new, а возможность explicit реализации интерфейса, но это уже далеко не классический мейнстримовый ООП и имеет весьма ограниченную область применения.
Именно что разрывает, по ссылке, кот. я привел выше:
When used as a declaration modifier, the new keyword explicitly hides a member that is inherited from a base class. When you hide an inherited member, the derived version of the member replaces the base class version.
Кодом людям нужно помогать!
Re[12]: почему в C# до сих пор нет наследования конструкторов?
P>Библиотека это совсем необязательно чтото, что надо подключать извне. Это может быть твоя собственная библиотека прямо в соседнем фолдере или даже просто в соседнем файле. P>Декораторы обычно являются такой библиотекой — на разные объекты навешиваем комбинации самых разных декораторов.
Я не считаю библиотекой, тем более декораторы, то, что пишется на самом языке в две строчки -- унаследовались
и передали в конструктор параметры. Какие фолдеры и соседние файлы? Оперирую базовыми сущностями языка.
S>>Книга эта есть, даже читал большую часть лет 10 назад. Но к чему был тот комментарий "за все хорошее против всего плохо" в контексте P>Я описал проблему, откуда она растет. Класс это два кейса в одном — и тип, и модуль, см эту самую книгу. И наследование, соответственно, тоже два кейса в одном — и уточнение типа, и расширение модуля. Отсюда ясно, что обозначеная проблема в нынешних реализациях ООП неустранима, принципиально. P>Вот скажем, если разделить subtype и extends, вроде бы круто, но я вот не сильно уверен, что на таком языке можно будет хоть что нибудь писать, т.к. такое смешение дает чудовищно мощный инструмент.
В шарпе есть как наследование, так и extension methods (т.е. extends). Можем специфицировать, можем
расширить. Опять же, для extends можно декоратор использовать.
Кодом людям нужно помогать!
Re[13]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>Я не считаю библиотекой, тем более декораторы, то, что пишется на самом языке в две строчки -- унаследовались
Хоть одну, это всё равно библиотечный спосою. Выделенной фичи для декораторов нет. Для наследования — есть, для классов — есть, для интерфейсов — тоже.
Всего два варианта — или выделеная фича, или её отсутствие
P>>Вот скажем, если разделить subtype и extends, вроде бы круто, но я вот не сильно уверен, что на таком языке можно будет хоть что нибудь писать, т.к. такое смешение дает чудовищно мощный инструмент.
S>В шарпе есть как наследование, так и extension methods (т.е. extends). Можем специфицировать, можем
Методы-расширения это круто. Только реализация наследования в C# от этого не меняется.
S>Опять же, для extends можно декоратор использовать.
Тогда нарушается основной признак декоратора. Декоратор он до тех пор декоратор, пока сохраняет базовый интерфейс. Это свойство позволяет комбинировать декораторы как попало.
Re[18]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Что угодно. Чем жирнее контракт, тем выше вероятность breaking changes
Только если он изначально плохо спроектирован.
НС>Если будут сами — будет известный и понятный юзкейс, под который можно вменяемо доработать public API.
Ага. Например, "вы там уже навелосипедили, значит, мне ничего менять и не надо".
Ад пуст, все бесы здесь.
Re[13]: почему в C# до сих пор нет наследования конструкторов?
В общем, я вижу, что дискуссия потеряла конструктивность.
Мне и нескольким довольно опытным коллегам запрошенная вами возможность представляется избыточной.
Но кто мы такие, чтобы навязывать вам свои предпочтения?
На страничке пакета всё, что нужно, написано. Добавляете этот пакет в зависимости своего проекта
Помечаете нужные вам классы атрибутом [InheritConstructors]
PROFIT!!!
Если шаг 1 делаете из студии, то её придётся перезапустить. Я пока не понял, как сделать так, чтобы при регистрации нового SourceGenerator/Analyzer остальные анализаторы не сворачивались трубочкой.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[14]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sinclair, Вы писали:
S>Мне и нескольким довольно опытным коллегам запрошенная вами возможность представляется избыточной.
Это те, которые пишут крайне странные вещи про метаданные базовых классов и наследование? Вижу, какой там "опыт".
S>Я пока не понял, как сделать так, чтобы при регистрации нового SourceGenerator/Analyzer остальные анализаторы не сворачивались трубочкой.
А, всего лишь
Ад пуст, все бесы здесь.
Re: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
C>есть внятные объяснения?
В общем случае класс-наследник определяет как именно конструировать его родителя — т.к. он знает чего он от родителя хочет. Родитель может иметь 5 конструкторов, а наследник — всего один конструктор. Если бы "наследование конструкторов" работало, всего у наследника было бы 6 конструкторов, из которых "адекватный" только один. Если вызвать один из родительских конструкторов, как именно наследническая часть должна инициализироваться? Мне кажется, что как оно сейчас сделано — это логично и предсказуемо.
Re[3]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали: S>>Я пока не понял, как сделать так, чтобы при регистрации нового SourceGenerator/Analyzer остальные анализаторы не сворачивались трубочкой. C>А, всего лишь
Я так понимаю, это какая-то известная проблема. Но после перезапуска студии она пропадает.
Так что если вам нужно массовое наследование конструкторов — велком.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[2]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, rosencrantz, Вы писали:
R>Если бы "наследование конструкторов" работало, всего у наследника было бы 6 конструкторов, из которых "адекватный" только один. Если вызвать один из родительских конструкторов, как именно наследническая часть должна инициализироваться? Мне кажется, что как оно сейчас сделано — это логично и предсказуемо.
Если "наследовать" все базовые ctors неявно, то конечно это неюзабельно, и вряд-ли это будет когда-либо сделано. А вот явно указать, что хочешь "наследовать" все базовые ctors, наподобие как в C++ (тут пример показали
), то почему бы и нет? Ну вот надо мне , при этом если я явно реализовал ctor соотв. сигнатуре какого-то базового ctor, то использовать его. Прозрачно это могло бы быть сделано на уровне компилятора, наподобие генерации тела авто-пропертей.
Re[15]: почему в C# до сих пор нет наследования конструкторов?
C>Регулярно задаюсь вопросом, каким местом они думают. Но, видимо, не головой.
Эмм. Налицо какая-то путаница. В исходной даденой вам ссылке опечатка: required не имеет отношения к обсуждаемому вопросу. Речь про init-only properties:
class TestClass
{
public int Prop1{ get; init;}
}
var obj = new TestClass { Field1 = 1, };
obj.Prop1= 2;
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[3]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, pilgrim_, Вы писали:
_>Если "наследовать" все базовые ctors неявно, то конечно это неюзабельно, и вряд-ли это будет когда-либо сделано. А вот явно указать, что хочешь "наследовать" все базовые ctors, наподобие как в C++ (тут пример показали
), то почему бы и нет? Ну вот надо мне , при этом если я явно реализовал ctor соотв. сигнатуре какого-то базового ctor, то использовать его. Прозрачно это могло бы быть сделано на уровне компилятора, наподобие генерации тела авто-пропертей.
Повторюсь, https://www.nuget.org/packages/Constructor.Inheritor/
Незачем курочить компилятор, когда то же самое можно сделать через набор библиотек
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
C>Регулярно задаюсь вопросом, каким местом они думают. Но, видимо, не головой.
required не про это, required про то, что поле/свойство необходимо инициализировать при создании, и компилятор не даст тебе это забыть или проигнорировать. Для баланса, так сказать, для тех кто не хочет по тем или иным причинам использовать конструктор, но нужно, чтобы свойство было проинициализировано.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Re[19]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
НС>>Я его проектирую по принципу — не делать вещей для которых нет известных use cases. C>То есть чем меньше, тем лучше для тебя.
Тенм лучше для всенх. При условии, разумеется, соответствия известным юзкейсам.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[19]: почему в C# до сих пор нет наследования конструкторо
Здравствуйте, Codealot, Вы писали:
НС>>Что угодно. Чем жирнее контракт, тем выше вероятность breaking changes C>Только если он изначально плохо спроектирован.
Это иллюзия, что можно так спроектировать что потом менять не придется.
НС>>Если будут сами — будет известный и понятный юзкейс, под который можно вменяемо доработать public API. C>Ага. Например, "вы там уже навелосипедили, значит, мне ничего менять и не надо".
Нет. Если велосипедирование причиняет боль или приводит к ошибкам — это отличный повод для изменений. А вот потому что тебе так кажется, что может когда нибудь понадобиться, мамой клянусь — плохой.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[17]: почему в C# до сих пор нет наследования конструкторо
Здравствуйте, Sharov, Вы писали:
S>>>Как причем? Декоратор реализуется в первую очередь посредством наследования НС>>Внезапно. Нет, не реализуется в первую очередь он наследованием, там может использоваться наследование если в конкретном языке нет способов поудобнее. А может и не использоваться. S>Внезапно мы про какой ЯП говорим?
Почему это важно?
S>Соотв. эта аргументация мимо.
Не понимаю. Почему мимо?
S>Судя по тому, что там 2 класса которые мы декорируем, то наследование исп. 100% из 100%.
Я тебе рассказал как обойтись без него. В ч5м проблема?
S> На счет BikeParts хотелось бы подробностей, поскольку кажется, что именно через спискок BikeParts, обеспечивающий дин. изм. поведения, как раз S>мало кто делает.
То что тебе кажется это не аргумент.
S>Именно что разрывает,
Именно что не разрывает.
S>по ссылке, кот. я привел выше: S>When used as a declaration modifier, [b]the new keyword explicitly hides a member that is inherited from a base class
Он hides только тогда, когда ты работаешь с новым типом явно. Стоит тебе привести его к базовому классу (а без такого приведения нет смысла в наследовании контрактов), и сразу же весь hide испаряется и ты получаешь исходный метод.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[13]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
НС>>Нет. Я объяснил почему другая. C>Не объяснил.
Интерфейсы это совсем другая история. Интерфейсы это чистая абстракция контракта, поэтому наследование интерфейсов между собой, в отличие от классов, чистое и не порождает никаких скрытых связей.
НС>>Удобно, все что не подходит под теорию объявить высосанным из пальца. C>Объясни, зачем конкретно тебе это надо
Чтобы продемострировать, почему одновременное и неразрываемое наследование и контракта и реализации это плохо.
НС>>Ясно, ответа не будет. ЧТД. C>Нет четкого описания требований — нет ответа.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Внезапно мы про какой ЯП говорим? НС>Почему это важно?
Потому что в шарпе декоратор прежде всего через наследование реализуется. В питоне через аттирбут можно.
S>>Судя по тому, что там 2 класса которые мы декорируем, то наследование исп. 100% из 100%. НС>Я тебе рассказал как обойтись без него. В ч5м проблема?
А зачем, чем этот подход хуже? Стандартный паттерн, т.е. подход.
S>> На счет BikeParts хотелось бы подробностей, поскольку кажется, что именно через спискок BikeParts, обеспечивающий дин. изм. поведения, как раз S>>мало кто делает. НС>То что тебе кажется это не аргумент.
Это и в обратную сторону работает. Привидите свой вариант кода и можно сравнить какой подход лучше.
S>>Именно что разрывает, НС>Именно что не разрывает.
Именно да -- для настройки связанности есть два взаимоискл. опции -- new и override.
override -- сцепляет, new -- разрывает.
S>>по ссылке, кот. я привел выше: S>>When used as a declaration modifier, [b]the new keyword explicitly hides a member that is inherited from a base class НС>Он hides только тогда, когда ты работаешь с новым типом явно. Стоит тебе привести его к базовому классу (а без такого приведения нет смысла в наследовании контрактов), и сразу же весь hide испаряется и ты получаешь исходный метод.
Именно, захотел -- прицепил с override, захотел -- отцепил с new.
А можно посмотреть на пример кода, где "Слишком сильная связность между предком и наследником, слишком низкая гибкость такой связи,"
А то в шарпе более чем гибские способы управлять наследованием.
Кодом людям нужно помогать!
Re[13]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>>>Внезапно мы про какой ЯП говорим? НС>>Почему это важно? S>Потому что в шарпе декоратор прежде всего через наследование реализуется.
Это утверждение нуждается в доказательстве.
S>>>Судя по тому, что там 2 класса которые мы декорируем, то наследование исп. 100% из 100%. НС>>Я тебе рассказал как обойтись без него. В ч5м проблема? S>А зачем
Чтобы продемонстрировать, что паттерн никуда не девается и не теряет своего смысла если наследование оттуда убрать.
S>>> На счет BikeParts хотелось бы подробностей, поскольку кажется, что именно через спискок BikeParts, обеспечивающий дин. изм. поведения, как раз S>>>мало кто делает. НС>>То что тебе кажется это не аргумент. S>Это и в обратную сторону работает.
Работает. Вот только я не пишу что мне что то там кажется.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[14]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Потому что в шарпе декоратор прежде всего через наследование реализуется. НС>Это утверждение нуждается в доказательстве.
Доказательство от противного -- без наследования классов или интерфейса в шарпе,
я не видел ни одной реализации паттерна декоратор.
S>>>>Судя по тому, что там 2 класса которые мы декорируем, то наследование исп. 100% из 100%. НС>>>Я тебе рассказал как обойтись без него. В ч5м проблема? S>>А зачем НС>Чтобы продемонстрировать, что паттерн никуда не девается и не теряет своего смысла если наследование оттуда убрать.
Ну так продемонтстрируйте кодом, если знаете как. В чем проблема?
S>>Это и в обратную сторону работает. НС>Работает. Вот только я не пишу что мне что то там кажется.
Покажите, код и всех делов.
Кодом людям нужно помогать!
Re[15]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>Доказательство от противного -- без наследования классов или интерфейса в шарпе,
Интерфейс не наследуется, он реализуется.
S>я не видел ни одной реализации паттерна декоратор.
Ну мало ли чего ты не видел.
НС>>Чтобы продемонстрировать, что паттерн никуда не девается и не теряет своего смысла если наследование оттуда убрать. S>Ну так продемонтстрируйте кодом, если знаете как. В чем проблема?
70 баксов в час и никаких проблем. А бесплатно придется тебе напрячься и понять написаное без готового кода.
НС>>Работает. Вот только я не пишу что мне что то там кажется. S>Покажите, код и всех делов.
70 баксов в час и всех делов
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[16]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Доказательство от противного -- без наследования классов или интерфейса в шарпе, НС>Интерфейс не наследуется, он реализуется.
Тем более.
S>>я не видел ни одной реализации паттерна декоратор. НС>Ну мало ли чего ты не видел.
S>>Ну так продемонтстрируйте кодом, если знаете как. В чем проблема? НС>70 баксов в час и никаких проблем. А бесплатно придется тебе напрячься и понять написаное без готового кода.
Ожидаемо. Что же там такого надо делать, что это час займет? Или час займет поиск в гугле соовт. реализаци, если она есть, конечно?
S>>Покажите, код и всех делов. НС>70 баксов в час и всех делов
Ожидаемо
Кодом людям нужно помогать!
Re[17]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>>>Доказательство от противного -- без наследования классов или интерфейса в шарпе, НС>>Интерфейс не наследуется, он реализуется. S>Тем более.
Не тем более. Это другой механизм, именно поэтому он и называется по другому. И то что ты неверно применяешь термин сути не меняет.
S>>>Ну так продемонтстрируйте кодом, если знаете как. В чем проблема? НС>>70 баксов в час и никаких проблем. А бесплатно придется тебе напрячься и понять написаное без готового кода. S>Ожидаемо. Что же там такого надо делать, что это час займет?
Да хоть 10 минут. Ты обладаешь уникальной наглостью требовать от других напрягаться только ради того чтобы тебе что то доказать, при том что ты сам подобным не озабачиваешься и лепишь бездоказательные утверждения сплошным потоком.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[18]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Ожидаемо. Что же там такого надо делать, что это час займет? НС>Да хоть 10 минут. Ты обладаешь уникальной наглостью требовать от других напрягаться только ради того чтобы тебе что то доказать, при том что ты сам подобным не озабачиваешься и лепишь бездоказательные утверждения сплошным потоком.
Классика! Был тезис:
Слишком сильная связность между предком и наследником, слишком низкая гибкость такой связи, неразрываемая и не настраиваемая связь между наследованием контракта и наследованием реализации.
Настраиваемая связь -- это паттерн декоратор, если virtual, override или new не хватает.
Гибкость связи: override -- привязываем к родителю, new -- отвязываем от родителя. Что может быть гибче?
Т.е нужен фрагмент кода, который подтверждал бы Ваш тезис, и невозможность как-то его изменить, что подтверждало бы
тезис про ненастраиваемость. В ответ -- уход от темы про способы реализации декоратора, и прочая обычная для Вас кака-бяка.
Кодом людям нужно помогать!
Re[19]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>Настраиваемая связь -- это паттерн декоратор, если virtual, override или new не хватает. S>Гибкость связи: override -- привязываем к родителю, new -- отвязываем от родителя. Что может быть гибче?
S>Т.е нужен фрагмент кода, который подтверждал бы Ваш тезис, и невозможность как-то его изменить, что подтверждало бы S>тезис про ненастраиваемость. В ответ -- уход от темы про способы реализации декоратора, и прочая обычная для Вас кака-бяка.
Ну вот смотрите, какая штука.
Допустим, вы хотите построить парсер некоторого DSL. Работать он будет, понятное дело, поверх некоторого StreamReader — хочется сделать его потоковым, и не зависеть от наличия в памяти всего разбираемого текста.
И вот вам захотелось иметь возможность репортить ошибки с привязкой к строка/позиция, а не просто "character #2213123".
Как вы это будете делать? Отнаследуетесь от SteamReader? Отнаследуетесь от TextReader? Сделаете свой класс, не отнаследованный ни от чего?
Какие методы придётся перекрыть? Какие — не придётся?
Это простое упражнение помогает прояснить различия между агрегацией, наследованием реализации, и наследованием интерфейса.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[4]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>Настраиваемая связь -- это паттерн декоратор, если virtual, override или new не хватает. S>Гибкость связи: override -- привязываем к родителю, new -- отвязываем от родителя. Что может быть гибче?
Я подозреваю, что речь идёт о том, что нужно классы реализовывать с оглядкой на их возможное расширение.
Не описал методы как virtual, не подготовил интерфейс — поимеешь проблемы.
Если это свои классы, то ещё можно их переделать, но может сломаться старый функционал.
С библиотечными классами будешь в пролёте, т.к. всё везде sealed, никакой виртуализации и т.п.
Захочешь в WPF класс MessageBox под себя подправить — делай свой с нуля, т.к. всё закрыто.
Re[5]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, karbofos42, Вы писали:
K>А зачем record добавили?
Клянусь, это не я!
А если без стёба, то source generators не могут изменять синтаксис языка.
Поэтому как ни крутись, а синтаксис record Person(string Firstname, string Lastname); через них не получишь.
Через SG можно получить только очень корявое и неудобное приближение к Record. Примерно такое:
[Record]
partial class Person {public string Firstname {get; set; } public string LastName { get; set; } }
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[6]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sinclair, Вы писали:
S>А если без стёба, то source generators не могут изменять синтаксис языка.
А это обязательно?
S>Поэтому как ни крутись, а синтаксис record Person(string Firstname, string Lastname); через них не получишь. S>Через SG можно получить только очень корявое и неудобное приближение к Record. Примерно такое:
Я с кодогенераторами не возился. А по field там нельзя свойства генерировать?
Получилась бы такая запись:
[Record]
partial class Person {string firstname; string lastName; }
что не далеко от изменённого языка ушло.
А ещё можно какой-нибудь t4 прикрутить или Fody.
Чего они язык то меняют ради плюшек каких-то, пусть все кодогенераторы прикручивают?
Re[7]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, karbofos42, Вы писали:
K>А это обязательно?
Ну, совсем-то обязательного вовсе ничего нет.
S>>Поэтому как ни крутись, а синтаксис record Person(string Firstname, string Lastname); через них не получишь. S>>Через SG можно получить только очень корявое и неудобное приближение к Record. Примерно такое:
K>Я с кодогенераторами не возился. А по field там нельзя свойства генерировать?
Можно, но опять же будут всякие сложности во всяких интересных случаях.
K>Получилась бы такая запись: K>
K>[Record]
K>partial class Person {string firstname; string lastName; }
K>
Возникает много мелких вопросов, вроде имён для этих свойств. Что, если пользователь напишет так?
[Record]
partial class Person {string Firstname; string LastName; }
Что, если он хочет, чтобы имена свойств были в camelCase?
Что, если он хочет какие-то дополнительные поля, по которым не нужно генерировать конструктор и расструктуривание?
Заставлять его размечать всё атрибутами?
Быстро теряется основное преимущество — компактность записи. Плюс ещё куча всяких corner case вроде наследования [Record] от не-[Record] и наоборот.
K>А ещё можно какой-нибудь t4 прикрутить или Fody. K>Чего они язык то меняют ради плюшек каких-то, пусть все кодогенераторы прикручивают?
Хорошая идея. Перед тем, как настаивать на изменениях в языке, стоит проверить — а не доступно ли то же самое через библиотеки.
Вот с конструкторами разницы в навешивании атрибута и навешивании нового ключевого слова практически нет (1 лишний keyword — partial, да и тот можно добавить батч-авто-фиксером).
А, скажем, static virtual interface methods или generic math реализовать через дополняющую кодогенерацию вообще никак невозможно, ни красиво, ни коряво.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[8]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sinclair, Вы писали:
S>Ну, совсем-то обязательного вовсе ничего нет.
Я к тому, что наследование конструкторов из коробки можно было сделать не изменением языка, а тем же атрибутом?
Ну, есть же CallerMemberNameAttribute и несколько других.
Или именно эту фичу обязательно через изменение языка и добавление ключевого слова реализовывать?
S>Вот с конструкторами разницы в навешивании атрибута и навешивании нового ключевого слова практически нет (1 лишний keyword — partial, да и тот можно добавить батч-авто-фиксером).
Ну, ещё очень удобно наверно искать реализацию вызываемого конструктора, когда Go to Definition будет отправлять в пустой сгенерированный конструктор, а оттуда в следующий и т.д.?
S>А, скажем, static virtual interface methods или generic math реализовать через дополняющую кодогенерацию вообще никак невозможно, ни красиво, ни коряво.
Костыли какие-то приделывают, а вот именно наследование конструкторов — это что-то ужасное, что испортит язык, что такому здесь не место.
Ещё можно вспомнить реализацию методов в интерфейсах. Такие методы "наследовать" можно и никаких проблем, а вот конструкторы — это всё от лукавого.
Re[20]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sinclair, Вы писали:
S>>Т.е нужен фрагмент кода, который подтверждал бы Ваш тезис, и невозможность как-то его изменить, что подтверждало бы S>>тезис про ненастраиваемость. В ответ -- уход от темы про способы реализации декоратора, и прочая обычная для Вас кака-бяка.
S>Ну вот смотрите, какая штука. S>Допустим, вы хотите построить парсер некоторого DSL. Работать он будет, понятное дело, поверх некоторого StreamReader — хочется сделать его потоковым, и не зависеть от наличия в памяти всего разбираемого текста. S>И вот вам захотелось иметь возможность репортить ошибки с привязкой к строка/позиция, а не просто "character #2213123". S>Как вы это будете делать? Отнаследуетесь от SteamReader? Отнаследуетесь от TextReader? Сделаете свой класс, не отнаследованный ни от чего? S>Какие методы придётся перекрыть? Какие — не придётся?
Скорее всего унаследуюсь от TR, но агрегирую SR, ибо надо позицию учитывать. Как-то так.
S>Это простое упражнение помогает прояснить различия между агрегацией, наследованием реализации, и наследованием интерфейса.
Мне казалось, я эту разницу понимаю.
Кодом людям нужно помогать!
Re[20]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, karbofos42, Вы писали:
K>Здравствуйте, Sharov, Вы писали:
S>>Настраиваемая связь -- это паттерн декоратор, если virtual, override или new не хватает. S>>Гибкость связи: override -- привязываем к родителю, new -- отвязываем от родителя. Что может быть гибче?
K>Я подозреваю, что речь идёт о том, что нужно классы реализовывать с оглядкой на их возможное расширение.
Так НС же не говорит, что конкретно не так. Общие фразы, без конкретики. Я привел возможные способы решения,
разговор ушел куда-то не туда.
K>Не описал методы как virtual, не подготовил интерфейс — поимеешь проблемы. K>Если это свои классы, то ещё можно их переделать, но может сломаться старый функционал.
Кривой дизайн и арх-ру язык не поправит. Он не для этого. А придать гибкости и настраиваемости -- пожалуйста.
K>С библиотечными классами будешь в пролёте, т.к. всё везде sealed, никакой виртуализации и т.п.
Ну значит не судьба, что тут поделаешь.
Кодом людям нужно помогать!
Re[9]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, karbofos42, Вы писали:
K>Я к тому, что наследование конструкторов из коробки можно было сделать не изменением языка, а тем же атрибутом?
Я вам дал ссылку на наследование конструкторов при помощи атрибута. Что не так-то?
K>Или именно эту фичу обязательно через изменение языка и добавление ключевого слова реализовывать?
Какую "эту"? Я что-то уже потерялся.
K>Ну, ещё очень удобно наверно искать реализацию вызываемого конструктора, когда Go to Definition будет отправлять в пустой сгенерированный конструктор, а оттуда в следующий и т.д.?
Ну да, всё верно. А что не так? Или вы хотели, чтобы навигация прыгала сразу в конструктор предка? А если он вручную выписан тоже как :base(...) {}? K>Костыли какие-то приделывают, а вот именно наследование конструкторов — это что-то ужасное, что испортит язык, что такому здесь не место.
Да почему испортит то?
В общем, я вас не понимаю. Двум людям на этом форуме вроде как нужна фича, которая позволяет не писать однообразные конструкторы.
Вам её дали — и опять что-то не нравится.
K>Ещё можно вспомнить реализацию методов в интерфейсах. Такие методы "наследовать" можно и никаких проблем, а вот конструкторы — это всё от лукавого.
Можно. Проблема у вас в чём? Как должна выглядеть фича про конструкторы, чтобы вас она устроила?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[10]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sinclair, Вы писали:
S>Я вам дал ссылку на наследование конструкторов при помощи атрибута. Что не так-то?
Что это криво работающая сторонняя примочка, а не стандартная возможность
S>Какую "эту"? Я что-то уже потерялся.
наследование конструкторов.
S>Ну да, всё верно. А что не так? Или вы хотели, чтобы навигация прыгала сразу в конструктор предка? А если он вручную выписан тоже как :base(...) {}?
Ну, при наследовании методов я прыгаю сразу на реализацию, а не блуждаю по закоулкам.
S>Да почему испортит то?
Если она не портит язык, то почему её не добавить?
S>В общем, я вас не понимаю. Двум людям на этом форуме вроде как нужна фича, которая позволяет не писать однообразные конструкторы. S>Вам её дали — и опять что-то не нравится.
Кривое решение, что в итоге проще и надёжнее ручками продолжить писать конструкторы.
S>Можно. Проблема у вас в чём? Как должна выглядеть фича про конструкторы, чтобы вас она устроила?
Фича должна выглядеть как что-то стандартное, для чего не нужно добавлять зависимости, создавать partial классы, танцевать с бубном и т.п.
Re[21]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>Скорее всего унаследуюсь от TR, но агрегирую SR, ибо надо позицию учитывать. Как-то так.
Ну, агрегировать (декорировать) надо скорее TextReader, потому что иначе у вас не будет возможности применить ваши наработки к альтернативным наследникам (например, StringReader). S>>Это простое упражнение помогает прояснить различия между агрегацией, наследованием реализации, и наследованием интерфейса.
S>Мне казалось, я эту разницу понимаю.
Ну, вот как раз тут и начинаются всякие интересные приплызды. Скажем, невозможно не отнаследоваться от TextReader — не существует интерфейса, который можно было бы реализовать при помощи прямого потомка object.
TextReader тащит за собой довольно-таки толстую реализацию, отказаться от которой вы не можете. Ещё в нём есть всякие неочевидные зависимости — повторюсь: какие методы вы будете перекрывать? Сможете сказать, не глядя в исходники? Как там с асинхронщиной — будет унаследованная реализация вам помогать или мешать? Может быть, вам захочется запретить асинхронное использование вашего декоратора — ан нет, нельзя, нет такого способа.
И это ещё относительно хорошо продуманный базовый класс. Специально разработанный для того, чтобы от него наследовались.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[11]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, karbofos42, Вы писали:
K>Что это криво работающая сторонняя примочка, а не стандартная возможность
Что-то конкретное не устраивает? Вы расскажите, мне интересен опыт использования из первых рук.
K>Если она не портит язык, то почему её не добавить?
А если портит?
K>Кривое решение, что в итоге проще и надёжнее ручками продолжить писать конструкторы. Ну, если проще — то пишите. Делов-то. Можно привести лошадь к воде, но вот пить её вы не заставите.
K>Фича должна выглядеть как что-то стандартное, для чего не нужно добавлять зависимости, создавать partial классы, танцевать с бубном и т.п.
Ок, пошли капризы. В общем, я понял — ехать вам не надо, надо шашечки.
На этом беседу можно сворачивать.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[12]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sinclair, Вы писали:
S>Что-то конкретное не устраивает? Вы расскажите, мне интересен опыт использования из первых рук.
Так я написал что не устраивает или повторить нужно?
S>А если портит?
Определитесь уже портит или не портит
S> Ну, если проще — то пишите. Делов-то. Можно привести лошадь к воде, но вот пить её вы не заставите.
Ну, вот до появления record, использовались какие-то кодогенераторы для получения подобного результата?
Или ручками писались всякие DTO и вроде нормально было?
S>Ок, пошли капризы. В общем, я понял — ехать вам не надо, надо шашечки.
Мне ехать на нормальном рабочем решении, а не на костылях сомнительного качества, не дающих при этом практически никакого удобства.
S>На этом беседу можно сворачивать.
Эта тема не имеет смысла уже давно, т.к. вместо ответов на вопрос какие-то пространные рассуждения.
Re[13]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, karbofos42, Вы писали: K>Так я написал что не устраивает или повторить нужно?
Вы не написали, что значит "криво". Какой именно случай непокрыт или покрыт неверно? У меня есть гипотезы, но ваши приоритеты гораздо важнее — мне-то такая фича вовсе не нужна. Это у вас есть какие-то сценарии, в которых такое автопорождение может быть полезным. Я про них ничего не знаю.
K>Определитесь уже портит или не портит
Тут всё просто. Смотрите: автонаследование без ключевого слова — сразу нет. Это резко поломает обратную совместимость большого количества кода, работающего в проде.
Автонаследование с ключевым словом — ну, так. Без реальной практики использования есть множество интересных вопросов про то, как это должно работать. То ли наследуем все конструкторы, то ли только помеченные специальным словом.
То ли наоборот тащим все, кроме помеченных специальным словом. То ли мы должны пометить спецсловом предка, то ли потомка, то ли обоих сразу.
Когда мы запекаем такую штуку в языке — всё, обратного хода нет. Библиотека позволяет каждому вташить в проект своё представление о прекрасном, никак не навязывая его всему остальному человечеству.
Если когда-то сложится консенсус по поводу фичи — можно и в язык её втащить. Точно так же, как магические атрибуты компилятора и рантайма.
Я бы при возможности голосовал за ещё большее перетаскивание языка в библиотеки — ну, как с теми же генераторами стейт-машин для асинков, или интерполяторами строк.
С нетерпением ждём переноса порождения Expression Trees из компилятора в библиотеки — это позволит куда как гибче и точнее обрабатывать выражения в нужных нам местах.
K>Ну, вот до появления record, использовались какие-то кодогенераторы для получения подобного результата?
До появления record source generator-ов не было. K>Или ручками писались всякие DTO и вроде нормально было?
Но да, те, кому было лень руками выписывать DTO, пользовались T4 и прочими генераторами API по схеме. S>>Ок, пошли капризы. В общем, я понял — ехать вам не надо, надо шашечки. K>Мне ехать на нормальном рабочем решении, а не на костылях сомнительного качества, не дающих при этом практически никакого удобства.
По-прежнему непонятно, какого именно удобства вам не хватает.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[21]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
K>>С библиотечными классами будешь в пролёте, т.к. всё везде sealed, никакой виртуализации и т.п. S>Ну значит не судьба, что тут поделаешь.
Это не судьба, это реальное свойство реальной технологии. Когда в учебниках и на модельных примерах все круто, а на практике получается больше проблем, чем пользы. Посмотри, к примеру, на дизайн Asp.Net Core — там и изначально то было немного наследования, меньше чем в прародителе, а со временем наследования там становится все меньше и меньше. Даже в очевидных вроде бы местах типа миддлверов, где, казалось бы, сам бог велел использовать какой нибудь базовый Middleware, на самом деле такого класса/интерфейса нет.
Или давай на ORM глянем — необходимость со стороны ORM наследовать классы модели от базового класса не заклеймил только ленивый.
Вообще, много можешь в .NET назвать относительно свежих API, где присутствует необходимость наследования от базового класса?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[14]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Чтобы продемострировать, почему одновременное и неразрываемое наследование и контракта и реализации это плохо.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это иллюзия, что можно так спроектировать что потом менять не придется.
И также иллюзия, что ничего проектировать не надо, а потом кривая как-нибудь вывезет.
НС>Нет. Если велосипедирование причиняет боль или приводит к ошибкам — это отличный повод для изменений.
Ага, серийный программист Джон.
Ад пуст, все бесы здесь.
Re[18]: почему в C# до сих пор нет наследования конструкторо
Здравствуйте, rameel, Вы писали:
R>required не про это, required про то, что поле/свойство необходимо инициализировать при создании, и компилятор не даст тебе это забыть или проигнорировать. Для баланса, так сказать, для тех кто не хочет по тем или иным причинам использовать конструктор, но нужно, чтобы свойство было проинициализировано.
Но потом все равно можно поменять. Странно, не?
Ад пуст, все бесы здесь.
Re[6]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали: C>Но потом все равно можно поменять. Странно, не?
Как по мне — так нет. Мутабельность ортогональна обязательности.
Мы же при изменениях всё контролируем — если нам нужно значение, удовлетворяющее какому-то сложному предикату, то мы это в сеттере проверим.
Остаётся только один способ пронести невалидное значение в объект — дефолт при конструировании. Вот, reqiured эту дырку закрывает.
А иммутабельность как была, так и осталась через readonly или init-only.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[18]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, karbofos42, Вы писали:
K>Здравствуйте, Baiker, Вы писали: B>>Что в C# налажали, так это вызов самих конструкторов. Если я правильно ошибаюсь, в Delphi можно вызывать базовый конструктор из любого места текущего конструктора. В C# это возможно только в начале.
K>И зачем эта фича нужна? K>Какие-то минимальные расчёты можно и в текущем варианте передать в вызове base.
А ты не думал, что конструкторов может быть несколько?? И какой из них вызывать и решают расчёты.
K>Если там какая-то сложная логика, то вообще странно в конструктор это пихать.
С чего бы "странно"?? Где удобно — там и делаю.
K>Тут уже какая-нибудь фабрика нужна, которая и асинхронность сможет предоставить.
Код — рабочим, фабрики — молодым клоунам-рассуждателям об ИТ. Не надо захламлять и без того сложные системы своими безумными Gang Of Fools.
Re[4]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Baiker, Вы писали:
B>А ты не думал, что конструкторов может быть несколько?? И какой из них вызывать и решают расчёты.
В чём проблема это сделать через фабричный метод?
B>С чего бы "странно"?? Где удобно — там и делаю.
Сегодня удобно, а завтра это всё обрастает дикими костылями, т.к. банально асинхронных конструкторов не завезли.
B>Код — рабочим, фабрики — молодым клоунам-рассуждателям об ИТ. Не надо захламлять и без того сложные системы своими безумными Gang Of Fools.
Так и не нужно делать сложные системы с замороченными конструкторами, когда входные параметры кардинально меняют стратегию инициализации объекта.
Может там вообще и не наследование в итоге нужно, а агрегация, раз уж такие разные конструкторы.
Re[19]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
C>Мда? То есть неизменяемое поле может быть необязательным?
Может, если его значение порождается конструктором (а не object initializer).
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[20]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
НС>>Это иллюзия, что можно так спроектировать что потом менять не придется. C>И также иллюзия, что ничего проектировать не надо, а потом кривая как-нибудь вывезет.
А такого никто и не предлагает. Предлагают проектировать код только исходя из известных/очень вероятных юзкейсов, и проектировать его так чтобы его было легко рефакторить.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[22]: почему в C# до сих пор нет наследования конструкторо
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Посмотри, к примеру, на дизайн Asp.Net Core
Хороший пример дизайна, за который надо пороть розгами.
НС>Вообще, много можешь в .NET назвать относительно свежих API, где присутствует необходимость наследования от базового класса?
MAUI
Ад пуст, все бесы здесь.
Re[21]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали: C>И это что-то меняет, с точки зрения использования, а не деталей реализации? В обоих случаях, оно обязательное.
Эмм, меняет. Без модификатора required свойство можно не инициализировать в object initializer.
Я правильно понимаю, что вы предлагаете компилятору считать init-only свойства автоматически required?
Это сломает обратную совместимость. Тем более, что автор кода, возможно, намеренно считает какие-то из init-only свойств необязательным. То есть класс спроектирован так, что default-значение этого свойства нас может и устроить. Поэтому не имеет смысла требовать явно задавать значение этому свойству в object initializer.
Здравствуйте, Codealot, Вы писали: C>Хороший пример дизайна, за который надо пороть розгами.
Очень, очень зря вы так. Впрочем, можете попробовать обоснованно покритиковать — будет интересно.
Я в потрохах ASP.Net не лазил со времён .Net 3.5; и уже тогда я был удивлён, узнав что он устроен не так, как я думал. С тех пор там очень много всего допилили — я краем глаза смотрю за доработками.
И в целом результат выглядит крайне достойно — в том смысле, что сочетает бешеную производительность с гибкостью при необходимости, а также с комфортном обычной мейнстримной разработки.
Прямо даже интересно, что такого там можно улучшить без того, чтобы уронить на дно одну из этих характеристик.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[22]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sinclair, Вы писали:
S>сочетает бешеную производительность с гибкостью при необходимости, а также с комфортном обычной мейнстримной разработки.
Такие утверждения надо чем-то доказывать.
Ад пуст, все бесы здесь.
Re[23]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
C>Ты говоришь о том, как оно уже сделано, и пытаешься использовать это как аргумент почему оно должно быть так сделано.
Ок, давайте зайдём с другой стороны — как вы предлагаете изменить то, что сделано? Добавить к init-only свойствам семантику required?
Мне сходу видится несколько неприятных особенностей такой реализации.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[25]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, karbofos42, Вы писали:
K>Здравствуйте, Baiker, Вы писали:
B>>А ты не думал, что конструкторов может быть несколько?? И какой из них вызывать и решают расчёты.
K>В чём проблема это сделать через фабричный метод?
В том, что в ЯЗЫКЕ нет никакой "фабрики"! (и не должно быть в принципе)
B>>С чего бы "странно"?? Где удобно — там и делаю.
K>Сегодня удобно, а завтра это всё обрастает дикими костылями, т.к. банально асинхронных конструкторов не завезли.
Вот блин затейник! асинхронность ещё... Походу, кто-то кончательно перемешал всё в голове — язык, паттерны, смузи, библиотеки... Сконцентрируйся на языке, не надо сюда тащить всякий новомодный мусор, да ещё придумывать на ходу "всё обрастает дикими костылями". А ЧТО Б* ЕСЛИ НЕТ?? (ц) Слепаков
B>>Код — рабочим, фабрики — молодым клоунам-рассуждателям об ИТ. Не надо захламлять и без того сложные системы своими безумными Gang Of Fools.
K>Так и не нужно делать сложные системы с замороченными конструкторами, когда входные параметры кардинально меняют стратегию инициализации объекта.
Тебе не нужно — не делай, а большим дядькам — не мешай! Задача языка — иметь гибкие абстракции для решения задач. Если какой-то клоун тупо скопировал Жабу и назвал C#, это ещё не повод бетонировать C# на идеях 90-ых. Если есть место для улучшения гибкости — его НАДО использовать.
Собственно, это и есть проблема закрытого междусобойчика "C# team" — они делают язык, но абсолютно оторваны от прикладных задач. И я не могу прийти к ним и сказать "запилите мне фичу, потому что у меня в "ТурбоСклад" можно написать код на 2 строки короче". Их тугодумский вселенский разум только лет через 5 озарится "да, ведь так можно решить ещё целый класс задач!". И ещё 5 лет уйдёт на обсуждения и реализацию.
Re[22]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это не судьба, это реальное свойство реальной технологии. Когда в учебниках и на модельных примерах все круто, а на практике получается больше проблем, чем пользы. Посмотри, к примеру, на дизайн Asp.Net Core — там и изначально то было немного наследования, меньше чем в прародителе, а со временем наследования там становится все меньше и меньше. Даже в очевидных вроде бы местах типа миддлверов, где, казалось бы, сам бог велел использовать какой нибудь базовый Middleware, на самом деле такого класса/интерфейса нет.
Ну побочный эффект наследования это динамическая диспетчерезация вызова методов, т.е. как минимум memory lookup, что для критичных
к производительности приложений может быть важно. Т.е. препочли производительность дизайну -- лучше написать класс с 0, чем
наследовать. Ок, это арх. выбор. За все надо платить, и где цена выше чем хотелось бы. Про asp.net core верю, ибо, кмк, вижу
в чем выгода.
НС>Или давай на ORM глянем — необходимость со стороны ORM наследовать классы модели от базового класса не заклеймил только ленивый.
Речь идет об инструментации или о явном наследовании? В любом случае хотелось ссылок на критику или объяснений. Тут уже
не так очевидно в чем проблема.
НС>Вообще, много можешь в .NET назвать относительно свежих API, где присутствует необходимость наследования от базового класса?
Я помню WWF был таким монстром с иерархией activities. Плюс, всяческие UI библиотеки. Зависит от, если критична производительность,
то наследования немного, иначе -- почему не сэкономить время и не переиспользовать компоненет?
Кодом людям нужно помогать!
Re[23]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>Ну побочный эффект наследования это динамическая диспетчерезация вызова методов, т.е. как минимум memory lookup, что для критичных S>к производительности приложений может быть важно.
Не, проблемы с производительностью там не причем, твоя теория не соответствует действительности. Причем там необходимость injection через параметры метода Next. Через ОО наследование такое не пролазит ни в каком виде.
НС>>Или давай на ORM глянем — необходимость со стороны ORM наследовать классы модели от базового класса не заклеймил только ленивый. S>Речь идет об инструментации или о явном наследовании?
Речь идет о наследовании. Ранние ORM требовали наследовать классы моделей от определенного типа. Или реализовывать определенный интерфейс, иногда опционально. А потом придумали POCO.
НС>>Вообще, много можешь в .NET назвать относительно свежих API, где присутствует необходимость наследования от базового класса? S>Я помню WWF был таким монстром с иерархией activities.
WWF это не относительно свежий.
S>Плюс, всяческие UI библиотеки.
У которых идеология тянется от событий 30-летней давности, ага. И даже при этом тот же WPF позволяет обходится без наследования в куда большем числе кейсов за счет display model и behaviors.
S>то наследования немного, иначе -- почему не сэкономить время и не переиспользовать компоненет?
Потому что экономия мнимая.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[22]: почему в C# до сих пор нет наследования конструкторов?
Политика вечной альфа-версии, когда постоянно что-нибудь меняют и что работало год назад, далеко не факт что будет работать сегодня. Многие совершенно тривиальные вещи, которые легко делались в ASP.NET, сейчас надо велосипедить.
Ад пуст, все бесы здесь.
Re[23]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
S>>Ну побочный эффект наследования это динамическая диспетчерезация вызова методов, т.е. как минимум memory lookup C>Это как?
Во время выполнения решается какой метод вызовется, в зависимости от типа объекта.
Кодом людям нужно помогать!
Re[25]: почему в C# до сих пор нет наследования конструкторов?
так там как раз про отсутствие скорости у .net core и как аффторам пришлось выдавать за .net core очень специфическое приложение заточенное на этот бенчмарк, где ничего из фрейморков нет.
Not even the interface IHttpApplication comes from ASP.NET Core. This is also a custom made type which was specifically designed for the benchmark tests.
Looking further into the BenchmarkApplication.cs I was shocked by the sheer amount of finely tuned low level C# code that was tailor made for this (extremely simple) application.
Everything inside the /PlatformBenchmarks folder is custom code which you won't find anywhere in an official ASP.NET Core package.
...
ASP.NET Core has many ways of implementing routing. They have Actions and Controllers, Endpoint Routing, Minimal APIs, or if someone wanted to operate on the lowest level of ASP.NET Core (= Platform), then they could work directly with the Request and Response objects from the HttpContext.
In fact, you won't find a HttpContext anywhere at all. It's almost like the .NET Team tried to avoid using ASP.NET Core at all cost, which is strange to say the least.
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Ну побочный эффект наследования это динамическая диспетчерезация вызова методов, т.е. как минимум memory lookup, что для критичных S>>к производительности приложений может быть важно. НС>Не, проблемы с производительностью там не причем, твоя теория не соответствует действительности. Причем там необходимость injection через параметры метода Next. Через ОО наследование такое не пролазит ни в каком виде.
О чем речь, к сожалению, я не большой знаток asp .net core?
НС>>>Или давай на ORM глянем — необходимость со стороны ORM наследовать классы модели от базового класса не заклеймил только ленивый. S>>Речь идет об инструментации или о явном наследовании?
НС>Речь идет о наследовании. Ранние ORM требовали наследовать классы моделей от определенного типа. Или реализовывать определенный интерфейс, иногда опционально. А потом придумали POCO.
1) Инструментация может добавлять наследование за кадром, на ORM классы можно посмотреть рефлектором. Но про EF не знаю,
а про Telerik OpenAccess знаю.
2) А как ORM среда будет отслеживать POCO объекты, если они ничего не реализуют и ни от чего не наследуются?
Ранние ORM требовали наследовать классы моделей от определенного типа.
Хотелось бы почитать критику этого подхода, а не просто было-стало. Причины каковы?
S>>Плюс, всяческие UI библиотеки. НС>У которых идеология тянется от событий 30-летней давности, ага. И даже при этом тот же WPF позволяет обходится без наследования в куда большем числе кейсов за счет display model и behaviors.
И что 30 летней давности? Идеи в основе языка C# и проч. мейнстирма еще древнее. В любом случае, если у нас есть грид, и нам
надо как-то его кастомизировать, то не проще ли базовый ф-ал унаследовать, прикрутив свои рющечки и как-то вклиниться в
жизненный цикл, чем делать гигансткую копипасту ради пары рющечек? Думается, что без наследования эволюция UI была бы крайне
медленная и затруднительная.
S>>то наследования немного, иначе -- почему не сэкономить время и не переиспользовать компоненет? НС>Потому что экономия мнимая.
Я с этим не согласен.
Кодом людям нужно помогать!
Re[31]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, Sharov, Вы писали: S>>А кто говорил про делегаты
Альтернативы чего? Вы зачем-то влезлки с делегатами, они в наследовании какую роль игарают?
C>У тебя есть другие альтернативы?
S>>и почему их вызов медленный? C>А почему нет?
Обоснуйте, можете кодом с замером, можете статье, где это обсуждается. Как я выше сслыку на вики дал.
Кодом людям нужно помогать!
Re[33]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>Альтернативы чего? Вы зачем-то влезлки с делегатами, они в наследовании какую роль игарают?
Ты написал, что виртуальные методы — не самая быстрая штука. Вот и возник вопрос, чем ты предлагаешь их заменить для этой задачи.
S>Обоснуйте, можете кодом с замером, можете статье, где это обсуждается. Как я выше сслыку на вики дал.
То есть, ты не знаешь о чем говоришь.
Ад пуст, все бесы здесь.
Re[34]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
S>>Альтернативы чего? Вы зачем-то влезлки с делегатами, они в наследовании какую роль игарают? C>Ты написал, что виртуальные методы — не самая быстрая штука. Вот и возник вопрос, чем ты предлагаешь их заменить для этой задачи.
Альтернатива не использовать наследование, о чем и речь ведется.
S>>Обоснуйте, можете кодом с замером, можете статье, где это обсуждается. Как я выше сслыку на вики дал. C>То есть, ты не знаешь о чем говоришь.
Т.е. Вы вперлись в разговор с какой-то хренью, не способны обосновать свои доводы, и просите, чтобы
другие за Вас обосновали. Успехов.
Кодом людям нужно помогать!
Re[25]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>О чем речь, к сожалению, я не большой знаток asp .net core?
Можно написать так:
class MyMiddleware
{
Task InvokeAsync(HttpContext context, ISomeService service) {...}
}
Выделенное — произвольный список необходимых сервисов.
S>1) Инструментация может добавлять наследование за кадром
Это совершенно неважно.
S>2) А как ORM среда будет отслеживать POCO объекты, если они ничего не реализуют и ни от чего не наследуются?
В каком смысле отслеживать и зачем?
S>
S> Ранние ORM требовали наследовать классы моделей от определенного типа.
S>Хотелось бы почитать критику этого подхода, а не просто было-стало. Причины каковы?
Гугль в помощь.
S>>>Плюс, всяческие UI библиотеки. НС>>У которых идеология тянется от событий 30-летней давности, ага. И даже при этом тот же WPF позволяет обходится без наследования в куда большем числе кейсов за счет display model и behaviors. S>И что 30 летней давности?
То, что 30 лет назад было немного другое понимание проблем дизайна.
S>В любом случае, если у нас есть грид, и нам S>надо как-то его кастомизировать, то не проще ли базовый ф-ал унаследовать, прикрутив свои рющечки
Не обязательно проще.
S>и как-то вклиниться в жизненный цикл, чем делать гигансткую копипасту ради пары рющечек?
Ты кроме наследования и копипасты других вариантов реюза кода не знаешь?
S>>>то наследования немного, иначе -- почему не сэкономить время и не переиспользовать компоненет? НС>>Потому что экономия мнимая. S>Я с этим не согласен.
Поздравляю.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[34]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
S>>Альтернативы чего? Вы зачем-то влезлки с делегатами, они в наследовании какую роль игарают? C>Ты написал, что виртуальные методы — не самая быстрая штука. Вот и возник вопрос, чем ты предлагаешь их заменить для этой задачи.
Там где перф настолько критичен в дотнете их заменяют динамической кодогенерацией чаще всего.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[26]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Sharov, Вы писали: S>>О чем речь, к сожалению, я не большой знаток asp .net core? НС>Можно написать так: НС>
НС>Выделенное — произвольный список необходимых сервисов.
И почему нельзя от какого-нибудь обобщенного Middleware унаследоваться?
S>>1) Инструментация может добавлять наследование за кадром НС>Это совершенно неважно.
Для POCO может и не важно. Кстати, а как с наследованием на уровне ORM, дискриминационные поля и т.п.?
S>>2) А как ORM среда будет отслеживать POCO объекты, если они ничего не реализуют и ни от чего не наседуются? НС>В каком смысле отслеживать и зачем?
Персистить изменения как? ну вот я некой отображенной сущности поменял значение, каким образом это отобразится
в бд?
S>>
S>> Ранние ORM требовали наследовать классы моделей от определенного типа.
S>>Хотелось бы почитать критику этого подхода, а не просто было-стало. Причины каковы? НС>Гугль в помощь.
Так не интересно, можно было бы свой тезис как-то весомее подтвердить.
S>>И что 30 летней давности? НС>То, что 30 лет назад было немного другое понимание проблем дизайна.
И что, в плане UI что изменилось? В плане парадигм, в том числе и ООП, что изменилось?
S>>В любом случае, если у нас есть грид, и нам S>>надо как-то его кастомизировать, то не проще ли базовый ф-ал унаследовать, прикрутив свои рющечки НС>Не обязательно проще.
А в чем будет усложнение?
S>>и как-то вклиниться в жизненный цикл, чем делать гигансткую копипасту ради пары рющечек? НС>Ты кроме наследования и копипасты других вариантов реюза кода не знаешь?
Есть аггрегация, но все равно фреймворк работает с объектами определенного типа.
Кодом людям нужно помогать!
Re[27]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>Персистить изменения как? ну вот я некой отображенной сущности поменял значение, каким образом это отобразится S>в бд?
Примерно так: https://linq2db.github.io/index.html#update
Трекинг и "автоматическое сохранение в БД" — это антипаттерны. Их использовать не надо.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[35]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
C>>Ты написал, что виртуальные методы — не самая быстрая штука. Вот и возник вопрос, чем ты предлагаешь их заменить для этой задачи.
НС>Там где перф настолько критичен в дотнете их заменяют динамической кодогенерацией чаще всего.
Где такое делается?
Кодом людям нужно помогать!
Re[27]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>И почему нельзя от какого-нибудь обобщенного Middleware унаследоваться?
Можно пример?
S>Кстати, а как с наследованием на уровне ORM, дискриминационные поля и т.п.?
Зависит от ORM. Большинство поддерживает три стандартных механихма — общая таблица с дискриминантом, отдельная таблица для каждого неабстрактного типа и таблицы-расширения. У каждого есть свои плюсы и минусы. Но не советую использовать ни один из них, наследование уж точно не для реляционной модели.
S>>>2) А как ORM среда будет отслеживать POCO объекты, если они ничего не реализуют и ни от чего не наседуются? НС>>В каком смысле отслеживать и зачем? S>Персистить изменения как? ну вот я некой отображенной сущности поменял значение, каким образом это отобразится S>в бд?
Запросом. Попытки уйти от реляционнолй модели в ОО добром не кончаются.
S>>>
S>>> Ранние ORM требовали наследовать классы моделей от определенного типа.
S>>>Хотелось бы почитать критику этого подхода, а не просто было-стало. Причины каковы? НС>>Гугль в помощь. S>Так не интересно, можно было бы свой тезис как-то весомее подтвердить.
Можно. $70/час.
S>>>И что 30 летней давности? НС>>То, что 30 лет назад было немного другое понимание проблем дизайна. S>И что, в плане UI что изменилось?
Изменилось. Десктопный UI сдох вместе с десктопом, а в вебе все несколько иначе, хотя попытки натянуть ОО были и будут.
S>>>В любом случае, если у нас есть грид, и нам S>>>надо как-то его кастомизировать, то не проще ли базовый ф-ал унаследовать, прикрутив свои рющечки НС>>Не обязательно проще. S>А в чем будет усложнение?
В развесистых иерархиях наследования, накладывающих очень жесткие ограничения на дизайн в силу высокой связности.
S>>>и как-то вклиниться в жизненный цикл, чем делать гигансткую копипасту ради пары рющечек? НС>>Ты кроме наследования и копипасты других вариантов реюза кода не знаешь? S>Есть аггрегация,
Открой GoF, там много всяких паттернов и далеко не все требуют наследования.
S> но все равно фреймворк работает с объектами определенного типа.
Какой фреймворк? О чем ты?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[36]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
НС>>Там где перф настолько критичен в дотнете их заменяют динамической кодогенерацией чаще всего. S>Где такое делается?
В куче мест. Тебя какая конкретно область интересует?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[37]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>>>Хочу посмотреть на реализацию тезиса НС>>Newtonsoft.Json/System.Text.Json подойдут? S>Да, было бы классно, если бы прямо в код ткнули.
Кто бы сомневался, что сам ты даже элементарных вещей делать не желаешь. Раз за разом одно и тоже.
Здравствуйте, Sharov, Вы писали:
S>Альтернатива не использовать наследование, о чем и речь ведется.
И какми конкретно инструментами ты собрался это реализовать? От делегатов ты открещиваешься. Свитч — еще медленнее, чем vtable. Ну так что, ты вообще понимаешь, о чем говоришь?
S>Т.е. Вы вперлись в разговор с какой-то хренью, не способны обосновать свои доводы, и просите, чтобы S>другие за Вас обосновали. Успехов.
Про хрень — см выше.
Ад пуст, все бесы здесь.
Re[35]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Зависит от ORM. Большинство поддерживает три стандартных механихма — общая таблица с дискриминантом, отдельная таблица для каждого неабстрактного типа и таблицы-расширения. У каждого есть свои плюсы и минусы. Но не советую использовать ни один из них, наследование уж точно не для реляционной модели.
Ага. Вообще, "наследование" в моделях данных — болезненная тема. В основном потому, что большинство маститых учебников его вовсе игнорируют, в итоге новобранцы неизменно пытаются применить подходы из ООП.
Которое вообще не про структуру, в про поведение.
У нас в рамках курса по базам данных все курсовые проекты полны моделями, в которых много is-a отношений.
И очень прикольно обсуждать со студентами, как подобные вещи выражать в ER-модели или в реляционной модели.
Ну, там, скажем, у станка на производстве есть список допущенных к нему рабочих, при этом у рабочего есть уровень квалификации, и у станка может быть задан минимальный уровень квалификации допущенного к нему работника.
А руководить отделом может только сотрудник с высшим образованием, подтверждённым дипломом.
При этом зарплата начисляется и тем и другим, т.е. зарплатная ведомость содержит ссылки на некоего "абстрактного сотрудника".
Какие из этих ограничений можно выразить в ER-модели? Какие — в реляционной? Какие стоит проверять динамически, в приложении?
И возникают множество всяких забавных вопросов, которые намеренно не оговорены в задании — скажем, может ли сотрудник быть одновременно менеджером и рабочим? Будем ли мы "наследовать" кого-то из них от другого, и если да, то как? И как быть с сотрудником, который начинал идти по рабочей линии, а потом стал менеджером?
На фоне этого вопросы о том, как и от кого наследовать DTO-классы, бледнеют
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[41]: почему в C# до сих пор нет наследования конструкторов?
Тут пишут, что дин. генерация для св-в, конструкторов и полей:
Moving retrieval of type metadata from runtime to compile-time means that there is less work for the serializer to do on start-up, which leads to a reduction in the amount of time it takes to perform the first serialization or deserialization of each type.
In previous versions of System.Text.Json, the serializer always used Reflection.Emit where possible to generate fast member accessors to constructors, properties, and fields. Generating these IL methods takes a non-trivial amount of time, but also consumes private memory. With source generators, we are able to generate code that that statically invokes these accessors. This eliminates time and allocation cost due to reflection.
Какая связь с вирт. методами и их оптимизацией путем генерации кода?
Кодом людям нужно помогать!
Re[28]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>И почему нельзя от какого-нибудь обобщенного Middleware унаследоваться? НС>Можно пример?
Не смогу, поскольку не до конца понимаю, что надо. Может выбрали интерфейс, т.к. по дизайну было лучше.
А не из-за производительности.
S>>И что, в плане UI что изменилось? НС>Изменилось. Десктопный UI сдох вместе с десктопом, а в вебе все несколько иначе, хотя попытки натянуть ОО были и будут.
Ну учитывая, что в js у нас prototype based наследование, едва ли они ушли от наследования per se. Т.е.
остутсвие классов не явл. проблемой для наследования в дин. языкых. Идея переиспользовать код она не толька для
чистых ОО актуальна и реализуема.
S>>А в чем будет усложнение? НС>В развесистых иерархиях наследования, накладывающих очень жесткие ограничения на дизайн в силу высокой связности.
Ну если у нас грид, то как textbox его странно использовать. Хотя можно как-то извратиться, наверное.
Или кнопка как tb.
S>> но все равно фреймворк работает с объектами определенного типа. НС>Какой фреймворк? О чем ты?
UI фреймворк, очевидно, типа WinForms. Почему-то все формы надо от Form наследовать.
Кодом людям нужно помогать!
Re[29]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>>>И почему нельзя от какого-нибудь обобщенного Middleware унаследоваться? НС>>Можно пример? S>Не смогу, поскольку не до конца понимаю, что надо.
S>>> но все равно фреймворк работает с объектами определенного типа. НС>>Какой фреймворк? О чем ты? S>UI фреймворк, очевидно, типа WinForms. Почему-то все формы надо от Form наследовать.
И что в этом хорошего? Почему в ASP.NET не надо контроллеры от одного объекта наследовать?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[29]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
НС>>Там где перф настолько критичен в дотнете их заменяют динамической кодогенерацией чаще всего. C>Это разве как-то отменяет необходимость в полиморфизме?
ВИртуальные методы — не единственный способ полиморфизма. И да, в ряде случаев отменяют. ПОтому что то, что может быть полиморфно на этапе компиляции исходников не обязательно полиморфно на этапе динамической генерации. К примеру, код Serialize(object obj) полиморфен, потому что obj может быть любого типа, а вот если там внутри написано что то вроде GenerateSerializer(obj.GetType()), то полиморфизм в сгенерированном коде уже не нужен.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[42]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S> generator.Emit(OpCodes.Callvirt, realMethod);
Callvirt может использоваться для вызова невиртуальных методов, ровно как Call — для вызова виртуальных. Callvirt в данном контексте более универсален, поэтому его и используют. А реальный вызов, виртуальный или нет, генерирует JIT. И если в аргументе будет невиртуальный метод — никакого виртуального вызова не будет.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[29]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>Почему? Из-за избыточности и сложности?
В основном — потому, что оно плохо совместимо с реальной архитектурой.
Единственное, для чего подходит change tracking — это такой нишевой случай "что вижу, то меняю".
Например, редактирование справочников. Фактически, редактор справочника в веб-приложении недалеко ушёл от той самой настольной программы, где на экран показываются почти что байты из файла данных, и пользователь их редактирует. Потом нажимает save, и обновлённые байты уезжают на диск.
Эта концепция опасна, в первую очередь, своей привлекательностью.
Разработчику, травмированному этой моделью, кажется, что любую бизнес-операцию можно реализовать поверх неё.
Ну, например — перевод денег внутри банка с моего счёта на счёт пользователя X.
Почему бы не представить это как две операции редактирования: уменьшаем остаток на моём счету, увеличиваем остаток на счету пользователя X?
Пока приложение бегало на локальной машинке поверх DBF файлов, это был совершенно нормальный способ работы.
А вот в современных крупномасштабных приложениях это начинает работать очень плохо.
В основном потому, что в change tracking у нас нет операции "уменьшить". У нас есть операции "загрузить в память" и "записать в СУБД".
В итоге вместо простого update accounts set balance = balance — @amount where id = @sourceAccount мы делаем сначала select * from accounts where id = @ID, а потом update accounts set balance = @balance where id = @id. То есть вместо 1 раундтрипа мы получили 2 раундтрипа.
При этом от времени между первым и вторым у нас ещё и зависит шанс нарваться на несогласованность — если мы делаем пессимистичную блокировку, то нам нужно не забыть об этом при селекте: select * from accounts where id = @ID with (holdlock), ну, или вообще все эти приплясывания выполнять в рамках транзакции с уровнем изоляции repeatable read.
Ну, или сделать optimistic locking и рисковать откатом транзакции потому, что кто-то вклинился между вызовами select и update.
В обоих вариантах мы затягиваем транзакцию, а это резко уменьшает возможное количество запросов, одновременно обслуживаемых СУБД.
Получается парадокс — мы уходим от, к примеру, хранимых процедур, чтобы разгрузить СУБД и перенести часть логики на легко масштабируемый слой сервера приложений, а нагрузка на СУБД только возросла .
Но это мы рассмотрели крошечный пример, с одним объектом простой структуры. В более сложных сценариях типа "зарезервировать товар на нескольких складах" у нас вот это вот общение между апп-сервером и СУБД сводится к затаскиванию в RAM половины базы и медленному неэффективному обходу получившегося графа объектов.
А потом мы ещё и пихаем в СУБД пачку update, по которым решительно непонятно, от каких же из сделанных ранее селектов они зависят.
Ну, и вишенка на торте — ничего этого не видно со стороны кода приложения. Там — сплошное благолепие, обращение к репозиториям, циклы-модификации. Понять, что происходит какой-то трэш, можно только подсмотрев в трафик СУБД при помощи какого-нибудь SQL Profiler.
В общем, такой код легко писать, но трудно тестировать/отлаживать, и невозможно исполнять эффективно.
Вообще, в этом же форуме было уже несколько горячих баталий по теме ORM. Там всё это было неоднократно высказано.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[37]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>ВИртуальные методы — не единственный способ полиморфизма.
Предлагай альтернативы. Кроме очевидных, которые работают на такой же скорости или медленнее.
НС>И да, в ряде случаев отменяют.
А в ряде случаев — нет.
НС>К примеру, код Serialize(object obj) полиморфен, потому что obj может быть любого типа, а вот если там внутри написано что то вроде GenerateSerializer(obj.GetType())
Это не полиморфизм, это reflection.
Ад пуст, все бесы здесь.
Re[38]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
C>Предлагай альтернативы. Кроме очевидных, которые работают на такой же скорости или медленнее.
Стесняюсь спросить: для какой задачи?
Идея обсуждать решения в отрыве от задачи лично мне видится в высшей степени странной.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[39]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sinclair, Вы писали:
S>Стесняюсь спросить: для какой задачи? S>Идея обсуждать решения в отрыве от задачи лично мне видится в высшей степени странной.
Для любой, где используются витртуальные методы. Хотя бы один пример.
Ад пуст, все бесы здесь.
Re[38]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
НС>>ВИртуальные методы — не единственный способ полиморфизма. C>Предлагай альтернативы. Кроме очевидных, которые работают на такой же скорости или медленнее.
Один я уже предложил — динамическая кодогенерация.
НС>>К примеру, код Serialize(object obj) полиморфен, потому что obj может быть любого типа, а вот если там внутри написано что то вроде GenerateSerializer(obj.GetType()) C>Это не полиморфизм, это reflection.
Это самый натуральный полиморфизм, обеспечивающий полиморфное поведение и скорость равносильную статическим вызовам. Есть еще статический полиморфизм, когда полный набор форм известене на этапе компиляции. В дотнете такое можно изобразить при помощи перегрузки функций или операторов. Есть еще параметрический полиморфизм, в дотнете представленный дженериками. Нам его базе есть интересные фокусы с использованием того факта, что статические поля дженерик класса для каждого дженерик параметра свои. Наконец, в свеженьком шарпе есть static virtual, который в рантайме не порождает виртуального вызова с адресацией через vtbl, а так же опирается на кодогенерацию дженериков JITом.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[36]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали: C>Свитч — еще медленнее, чем vtable.
// * Summary *
BenchmarkDotNet=v0.13.2, OS=Windows 10 (10.0.19045.2251)
Intel Core i7-8565U CPU 1.80GHz (Whiskey Lake), 1 CPU, 8 logical and 4 physical cores
.NET SDK=6.0.401
[Host] : .NET 6.0.9 (6.0.922.41905), X64 RyuJIT AVX2
DefaultJob : .NET 6.0.9 (6.0.922.41905), X64 RyuJIT AVX2
| Method | Mean | Error | StdDev |
|-------- |---------:|--------:|--------:|
| Virtual | 189.0 us | 3.77 us | 4.03 us |
| Switch | 178.2 us | 2.98 us | 3.19 us |
Код теста
using BenchmarkDotNet.Attributes;
using BenchmarkDotNet.Running;
BenchmarkRunner.Run<SwitchVsVirtual>();
public class SwitchVsVirtual
{
private readonly Base[] _vData;
private readonly SwitchData[] _sData;
public SwitchVsVirtual()
{
var rnd = new Random(Environment.TickCount);
var randoms = Enumerable.Range(0, 10000).Select(_ => rnd.Next(0, 3)).ToArray();
_vData = randoms
.Select(r => r switch {
0 => (Base)new DerivedA(),
1 => new DerivedB(),
2 => new DerivedC(),
_ => throw new ArgumentOutOfRangeException()
})
.ToArray();
_sData = randoms
.Select(r => new SwitchData(r switch {
0 => Discriminant.A,
1 => Discriminant.B,
2 => Discriminant.C,
_ => throw new ArgumentOutOfRangeException()
}))
.ToArray();
}
[Benchmark]
public int Virtual()
{
var res = 0;
foreach (var data in _vData)
res += data.Data.Length;
return res;
}
[Benchmark]
public int Switch()
{
var res = 0;
foreach (var d in _sData)
res += d.Data.Length;
return res;
}
}
abstract class Base
{
public abstract string Data { get; }
}
class DerivedA : Base
{
public override string Data => "A";
}
class DerivedB : Base
{
public override string Data => "B";
}
class DerivedC : Base
{
public override string Data => "C";
}
enum Discriminant { A, B, C }
record SwitchData(Discriminant Discriminant)
{
public string Data =>
Discriminant switch
{
Discriminant.A => "A",
Discriminant.B => "B",
Discriminant.C => "C",
_ => throw new ArgumentOutOfRangeException()
};
}
C> Ну так что, ты вообще понимаешь, о чем говоришь?
А ты?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[43]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>> generator.Emit(OpCodes.Callvirt, realMethod); НС>Callvirt может использоваться для вызова невиртуальных методов, ровно как Call — для вызова виртуальных. Callvirt в данном контексте более универсален, поэтому его и используют. А реальный вызов, виртуальный или нет, генерирует JIT. И если в аргументе будет невиртуальный метод — никакого виртуального вызова не будет.
Ну и в чем тогда смысл оптимизации, если ключеое слово "если". А если будет виртуальный метод, то в чем смысл оптимизации?
Я выше привел цитату для чего этот код нужен:
In previous versions of System.Text.Json, the serializer always used Reflection.Emit where possible to generate fast member accessors to constructors, properties, and fields. Generating these IL methods takes a non-trivial amount of time, but also consumes private memory. With source generators, we are able to generate code that that statically invokes these accessors. This eliminates time and allocation cost due to reflection.
Но где там про виртуальные методы и их замену генерацией кода?
Кодом людям нужно помогать!
Re[30]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Не смогу, поскольку не до конца понимаю, что надо. НС>
По каким-то сообржениям, скорее производительности, решили не связываться с абстрактным middleware
и абстрактными методами, заменив их на интерфейс. Для DI будет проще.
S>>UI фреймворк, очевидно, типа WinForms. Почему-то все формы надо от Form наследовать. НС>И что в этом хорошего? Почему в ASP.NET не надо контроллеры от одного объекта наследовать?
А что плохого? Зачем сравнивать холодное с мягким -- развесистый UI и контроллер, задачи которого брать
данные из модели и передавать во view(или обратно) + всяческая bl. А сколько всего навешано для работы грида, и каждый
раз писать заново или копипаста, да еще сохранить совместимость, т.е. там где ждуть тип Grid, наш самодельный
грид также должен подходить. В общем, не вижу альтернативы наследованию.
Кодом людям нужно помогать!
Re[39]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали: НС>Это самый натуральный полиморфизм, обеспечивающий полиморфное поведение и скорость равносильную статическим вызовам. Есть еще статический полиморфизм, когда полный набор форм известене на этапе компиляции. В дотнете такое можно изобразить при помощи перегрузки функций или операторов. Есть еще параметрический полиморфизм, в дотнете представленный дженериками. Нам его базе есть интересные фокусы с использованием того факта, что статические поля дженерик класса для каждого дженерик параметра свои. Наконец, в свеженьком шарпе есть static virtual, который в рантайме не порождает виртуального вызова с адресацией через vtbl, а так же опирается на кодогенерацию дженериков JITом.
Кстати, там пока что на мой вкус всё довольно сыренько.
Самое весёлое — это наличие "скрытых" статических методов в классе.
Если мы делаем явную реализацию экземплярного метода, то до него можно добраться путём каста экземпляра к интерфейсу:
public interface IFoo
{
void Foo();
}
public class Foo: IFoo
{
void IFoo.Foo()=> Console.WriteLine("Foo!");
}
...
var foo = new Foo();
foo.Foo(); // doesn't compile
((IFoo)foo).Foo(); // ok
А вот если у нас аналогичным образом реализован static virtual, то кабзда. Его можно вызвать только в generic-контексте, т.к. приводить к интерфейсу нечего.
К примеру — попробоуйте вызвать TryReadBigEndian для типа short или int.
Здравствуйте, Sharov, Вы писали:
S>>>Не смогу, поскольку не до конца понимаю, что надо. НС>> S>По каким-то сообржениям, скорее производительности, решили не связываться с абстрактным middleware S>и абстрактными методами, заменив их на интерфейс. Для DI будет проще.
Т.е. ты нифига не знаешь, высасываешь из пальца какой то ничем необоснованный бред про производительность, а потом еще и споришь с теми кто знает. Поэтому
S>>>UI фреймворк, очевидно, типа WinForms. Почему-то все формы надо от Form наследовать. НС>>И что в этом хорошего? Почему в ASP.NET не надо контроллеры от одного объекта наследовать? S>А что плохого?
Лишние ограничения на дизайн, лишняя связность.
S>Зачем сравнивать холодное с мягким -- развесистый UI и контроллер
Затем что они решают похожие задачи.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[40]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sinclair, Вы писали:
S>Его можно вызвать только в generic-контексте
Да. Он для этого и придуман — обеспечить перегрузку операторов и методов по дженерик-параметру. Таким образом ты можешь получить вызов разных статических методов в зависимости от параметра, единожды написав дженерик код. Основной юзкейс — дженерик-арифметика для числомолотилок.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[41]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Да. Он для этого и придуман — обеспечить перегрузку операторов и методов по дженерик-параметру. Таким образом ты можешь получить вызов разных статических методов в зависимости от параметра, единожды написав дженерик код. Основной юзкейс — дженерик-арифметика для числомолотилок.
Ну, это понятно. Непонятно, по большому счёту, почему я не могу вызвать этот метод для конкретного типа.
Я понимаю, что, скажем, TryParse я теперь могу вызывать не на конкретном int или long, а на любом T, который реализует IParsable<T>. Но давать методы, которые доступны только в generic-контексте, странно
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[37]: почему в C# до сих пор нет наследования конструкторов?
| Method | Mean | Error | StdDev |
|-------- |---------:|---------:|---------:|
| Virtual | 67.88 us | 0.158 us | 0.148 us |
| Switch | 70.84 us | 0.093 us | 0.087 us |
Подтасовываешь данные в надежде, что я не стану проверять?
Ад пуст, все бесы здесь.
Re[39]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это самый натуральный полиморфизм, обеспечивающий полиморфное поведение и скорость равносильную статическим вызовам.
Это не имеет никакого отношения к виртуальным методам, о которых шла речь. От слова вообще.
Ад пуст, все бесы здесь.
Re[32]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>По каким-то сообржениям, скорее производительности, решили не связываться с абстрактным middleware S>>и абстрактными методами, заменив их на интерфейс. Для DI будет проще. НС>Т.е. ты нифига не знаешь, высасываешь из пальца какой то ничем необоснованный бред про производительность, а потом еще и споришь с теми кто знает. Поэтому
Ну-ну-ну, я пытался ответить на вопрос, почему в asp .net core (и вообще asp.net), они решили обойтись
интерфейсом, а не наследованием. Дескать, из-за наследования будет лишний оверхед в виде vt.
Почему-то обосновать что это "необоснованный бред" никто пока не смог. В ответ ор, кака-бяка и переход
на личности. Т.е. вместо того, чтобы дать ответь, если он есть, идет ходьба вокруг да около.
S>>А что плохого? НС>Лишние ограничения на дизайн, лишняя связность.
Так может для UI это хорошо? Там куча кода для тех же гридов и проч. контролов, и все
это предлагается убрать за интерфейс и писать с нуля? Или через композицию, где будет
куча методов типа
class NewGrid: IGrid
{
....
private readonly Grid _oldGrid;
public void Redraw(){
_oldGrid.Redraw()
}
...
}
И все это, чтобы поменять две-три строчки метода в одном-двух методах. Ну такое себе.
Наследование здесь явно выигрывает и лишняя связность тут явно к месту.
S>>Зачем сравнивать холодное с мягким -- развесистый UI и контроллер НС>Затем что они решают похожие задачи.
Ну не сказал бы -- Forms это больше UI+контроллер (причем, скороее UI), а asp .net контроллер, внезапно, просто
контроллер, у которого будет отдельный View. Контроллеру развесистая иерархия ни к чему.
Кодом людям нужно помогать!
Re[38]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
НС>>Это самый натуральный полиморфизм, обеспечивающий полиморфное поведение и скорость равносильную статическим вызовам. C>Это не имеет никакого отношения к виртуальным методам, о которых шла речь. От слова вообще.
Смотри шире. Есть задача полиморфного поведения, когда вызываемый код ведет себя по разному в зависимости от состояния. Виртуальные методы — один из способов это получить. Динамическая кодогенерация — другой.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[33]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>Ну-ну-ну, я пытался ответить на вопрос, почему в asp .net core (и вообще asp.net), они решили обойтись S>интерфейсом, а не наследованием.
Интерфейс там торже необязателен. И мне не лень, я тебе четвертый раз повторю — ты не прав.
S>В ответ ор, кака-бяка и переход на личности.
Переход на личности был после того как ты три раза пропустил мимо ушей, что ты не прав в своей теории.
S>Т.е. вместо того, чтобы дать ответь
В пятый раз тебе ответь — ты не прав.
S>>>А что плохого? НС>>Лишние ограничения на дизайн, лишняя связность. S>Так может для UI это хорошо?
Это ни для чего не хорошо. Low coupling/high cohesion это самый базовый принцип дизайна софта, все остальное — следствие.
S>>>Зачем сравнивать холодное с мягким -- развесистый UI и контроллер НС>>Затем что они решают похожие задачи. S>Ну не сказал бы -- Forms это больше UI+контроллер (причем, скороее UI)
Ага. И за это их не пнул только ленивый. А потом начали изобретать всякие MVC и MVVM, хотя налазит это все на винформсы, в отличие от aspnet, аки сова на глобус.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[34]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ага. И за это их не пнул только ленивый. А потом начали изобретать всякие MVC и MVVM, хотя налазит это все на винформсы, в отличие от aspnet, аки сова на глобус.
в WPF примерно такое же наследование, как и в формах, а MVVM там родной изначально.
Re[35]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, karbofos42, Вы писали:
НС>>Ага. И за это их не пнул только ленивый. А потом начали изобретать всякие MVC и MVVM, хотя налазит это все на винформсы, в отличие от aspnet, аки сова на глобус. K>в WPF примерно такое же наследование, как и в формах
Такое, да не совсем.
K>а MVVM там родной изначально.
Если бы. Прикручивание туда MVVM вызывает преизрядно проблем с несовместимостью, хотя, конечно, там это сильно проще чем в винформсах. Как раз в силу меньшей связности дизайна WPF.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[39]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Смотри шире. Есть задача полиморфного поведения, когда вызываемый код ведет себя по разному в зависимости от состояния. Виртуальные методы — один из способов это получить. Динамическая кодогенерация — другой.
Здесь речь шла о виртуальных методах, от которых предлагалось как-то отказаться. Точка.
Ад пуст, все бесы здесь.
Re[34]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Ну-ну-ну, я пытался ответить на вопрос, почему в asp .net core (и вообще asp.net), они решили обойтись S>>интерфейсом, а не наследованием. НС>Интерфейс там торже необязателен. И мне не лень, я тебе четвертый раз повторю — ты не прав.
Да пожалуйста, просто никакого обоснования почему не прав не было. Вместо того, чтобы объяснить 2-3 предложения
или кинуть ссылку на обсуждение в SO или msdn, какая-то кака-бяка и хождение по кругу. "Ты не прав потому и потому",
и всех делов. А не "покажи" или "докажи".
S>>В ответ ор, кака-бяка и переход на личности. НС>Переход на личности был после того как ты три раза пропустил мимо ушей, что ты не прав в своей теории.
Я высказал гипотезу, почему было отвергнуто то или иное решение -- в ответ ничего вразумительного.
Я могу заблуждаться, но хотелось бы понять где, а в ответ что-то врод "я -- начальник, ты -- дурак".
S>>Т.е. вместо того, чтобы дать ответь НС>В пятый раз тебе ответь — ты не прав.
См. выше.
S>>Так может для UI это хорошо? НС>Это ни для чего не хорошо. Low coupling/high cohesion это самый базовый принцип дизайна софта, все остальное — следствие.
Конкретно для UI это хорошо. У меня есть базовых грид (Grid) для которого написана куча кода, целый фреймворк+компоненты,
мне надо как-то кастомизировать его поведение (NewGrid), чтобы вместо textbox ячеек где-то показывать checkbox.
Причем NewGrid должен рабоать где и Grid, т.е. как грамотно сказать, NewGrid полиморфен Grid.
Как без наследования максимально эффективно этого добиться?
S>>Ну не сказал бы -- Forms это больше UI+контроллер (причем, скороее UI) НС>Ага. И за это их не пнул только ленивый. А потом начали изобретать всякие MVC и MVVM, хотя налазит это все на винформсы, в отличие от aspnet, аки сова на глобус.
Ага не ага, а сравнения UI и контроллера было некорректным.
Кодом людям нужно помогать!
Re[40]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, rameel, Вы писали:
R>С чего бы это будет так работать?! Если дыр нет, то все работает за константное время, и не важно 10 там элементов или 1000
Это свитч то за константное время, когда у него 1000 вариантов?
Ад пуст, все бесы здесь.
Re[42]: почему в C# до сих пор нет наследования конструкторов?
См. выше.
S>>>Так может для UI это хорошо? НС>>Это ни для чего не хорошо. Low coupling/high cohesion это самый базовый принцип дизайна софта, все остальное — следствие. S>Конкретно для UI это хорошо.
Аксиома?
S>Как без наследования максимально эффективно этого добиться?
Здравствуйте, Codealot, Вы писали:
НС>>Смотри шире. Есть задача полиморфного поведения, когда вызываемый код ведет себя по разному в зависимости от состояния. Виртуальные методы — один из способов это получить. Динамическая кодогенерация — другой. C>Здесь речь шла о виртуальных методах
Нет, речь шла о полиморфизме
C>Это разве как-то отменяет необходимость в полиморфизме?
НС>ВИртуальные методы — не единственный способ полиморфизма.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[36]: почему в C# до сих пор нет наследования конструкторов?
А как еще отвечат на то, что ты придумываешь бредовые гипотезы без какого либо обоснолвания и требуешь их опровергать? Рассел как раз для таких как ты свой чайник придумал.
S>>>Конкретно для UI это хорошо. НС>>Аксиома? S>Скорее практика.
Чья практика?
S>Да и на потомков можно глянуть. А так да, никакого наследования в UI нет и быть не должно.
О, то самое имаго за которое ты переживал. Я не говорил что наследования в UI нет, я говорил что его широкое распространение вызвано в основном историческими причинами, набором идеом которые зародились еще в TurboVision и расцвели пышным цветом в VCL. И винформсы прямой наследник VCL, того же автора.
В WPF же от наследования стали уходить (частично, не полностью, а то ты опять себе соломенное чучелко изобразишь), чему приведенный пример отличное доказательство. Ровно как и отличная демонстрация инерции мышления, когда ты даже представить себе не мог, что описанная тобой задача прекрасно решается без наследования. И именно эта инерция в первую очередь приводит к традиционному дизайну UI с развесистой иерархией контролов.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[38]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Как и ожидалось, никакого вразумительного объяснения не будет. НС>А как еще отвечат на то, что ты придумываешь бредовые гипотезы без какого либо обоснолвания и требуешь их опровергать? Рассел как раз для таких как ты свой чайник придумал.
1)Что конкретно бредового в моей гипотезе? Обоснования -- избегать вызова виртуальных методов по hot-path.
Не очень здорово при нагрузке.
2)Огласите правильный вариант, если знаете почему в asp.net core избегают наследования, в частности в middleware.
S>>Скорее практика. НС>Чья практика?
Судя по всему, ms.
S>>Да и на потомков можно глянуть. А так да, никакого наследования в UI нет и быть не должно.
НС>О, то самое имаго за которое ты переживал. Я не говорил что наследования в UI нет, я говорил что его широкое распространение вызвано в основном историческими причинами, набором идеом которые зародились еще в TurboVision и расцвели пышным цветом в VCL. И винформсы прямой наследник VCL, того же автора.
Какие исторические причины у написанного с нуля wpf, если там цепочки наследования чуть ли не удвоились
по сравнению с winforms? Как минимум не уменьшились со времен wf. Про turbovision не знаю, все это началось еще раньше,
со smalltalk'а и его программной среды. Т.е. ui расцвел вместе с ООП.
НС>В WPF же от наследования стали уходить (частично, не полностью, а то ты опять себе соломенное чучелко изобразишь), чему приведенный пример отличное доказательство. Ровно как и отличная демонстрация инерции мышления, когда ты даже представить себе не мог, что описанная тобой задача прекрасно решается без наследования. И именно эта инерция в первую очередь приводит к традиционному дизайну UI с развесистой иерархией контролов.
У меня есть большой опыт с wf, а с wpf практически нету. Но вот глядя на стандартные контролы wpf и цепочку наследований для них,
я не вижу что они стали уходить от наследования, хотя бы частично. Кмк, еще больше углубились по сравнению с wf. И как бэ такая
гибкость была не за счет такой большой иерархии наследования.
Кодом людям нужно помогать!
Re[38]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>В WPF же от наследования стали уходить (частично, не полностью, а то ты опять себе соломенное чучелко изобразишь), чему приведенный пример отличное доказательство.
Далеко ушли?
Берём обычную кнопку из WinForms:
Object — MarshalByRefObject — Component — Control — ButtonBase — Button
Кнопка в WPF:
Object — DispatcherObject — DependencyObject — Visual — UIElement — FrameworkElement — Control — ContentControl — ButtonBase — Button
Ушли от наследования, так ушли.
Другой подход к изменению контролов и ту же кнопку в WPF можно перерисовать без наследования и создания отдельного типа.
Но вот внутри самого фреймворка никуда они от наследования не уходили и во всю используют.
Re[41]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Нет, речь шла о полиморфизме
Да, с внимательностью у тебя серьезные проблемы. Напомню, откуда все началось:
S>По ссылке все написано -- вызов виртуальных методов не самая быстрая штука.
Ад пуст, все бесы здесь.
Re[39]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>2)Огласите правильный вариант, если знаете почему в asp.net core избегают наследования, в частности в middleware.
Фантастическое неуважение к собеседнику.
S>>>Скорее практика. НС>>Чья практика? S>Судя по всему, ms.
О, опять пошли неуемные фантазии.
НС>>О, то самое имаго за которое ты переживал. Я не говорил что наследования в UI нет, я говорил что его широкое распространение вызвано в основном историческими причинами, набором идеом которые зародились еще в TurboVision и расцвели пышным цветом в VCL. И винформсы прямой наследник VCL, того же автора. S>Какие исторические причины у написанного с нуля wpf,
Архитекторы, его проектировавшие — тоже с нуля? Люди не идеальны, у людей бэкграунд и инерция (ты вот сам был уверен, что для добавления чекбокса в грид наследование must have). Один из архитектов WPF, к примеру, заодно еще и архитектором SOAP был. Рассказать в каком месте сейчас SOAP и вообще идея OO-RPC?
S> если там цепочки наследования чуть ли не удвоились
Неважно что там удвоилось. Важно что типичные кейсы, которые раньше требовали наследования, сейчас обходятся без них. Можно написать вполне полноценную программу на WPF практически не наследуясь руками от библиотечных классов (генераторы WPF не в счет).
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[39]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, karbofos42, Вы писали:
K>Берём обычную кнопку из WinForms:
Я вроде понятно объяснил, но нет.
Неважно что там в цепочке наследования. Если ее в 3 раза сократить — ничего не изменится. Важно другое. В винформсах чтобы изменить отрисовку кнопки или при нажатии на нее издатьт пук обязательно требовалось наследование. В WPF наследование для этого не требуется. Наследование требуется только тогда, когда тебе надо расширить контракт (ибо в C#, особенно в C# 2.0, актуальном на момент проектирования WPF альтернатив наследованию было совсем немного).
K>Но вот внутри самого фреймворка никуда они от наследования не уходили и во всю используют.
И что? Почему это важно?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[42]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Я вроде понятно объяснил, но нет. НС>Неважно что там в цепочке наследования. Если ее в 3 раза сократить — ничего не изменится. Важно другое. В винформсах чтобы изменить отрисовку кнопки или при нажатии на нее издатьт пук обязательно требовалось наследование. В WPF наследование для этого не требуется. Наследование требуется только тогда, когда тебе надо расширить контракт
В итоге примерно так же как и в формах, в WPF тоже постоянно делаешь наследников и меняешь поведение. Стилизацию контролов упростили и прочие мелочи.
А захочешь какой-нибудь нормальный CheckBoxList — всё равно не прокатит просто прописать у ListBox ItemTemplate, чтобы там были CheckBox. Этим не получится нормально пользоваться и придётся огород городить.
Можно было просто в формах добавить какие-то нормальные методы для отрисовки кнопок, CheckBox и т.п. Чтобы это не становилось проблемой, когда захочется сделать какой-то свой контрол.
НС>(ибо в C#, особенно в C# 2.0, актуальном на момент проектирования WPF альтернатив наследованию было совсем немного).
А что появилось сейчас? Кодогенераторы, которые позволяют дублировать функционал без наследования?
НС>И что? Почему это важно?
Ну, не я тут пишу, что наследование плохо, виртуальные методы медленные и нужно всё делать иначе.
Я не знаю как без наследования всё это красиво сделать и не вижу проблемы в правильных иерархиях.
Я вижу проблему, когда в теории WPF весь такой настраиваемый и замечательный, а потом банальный MessageBox расширить никак не можешь и делаешь свою поделку.
И мне как-то без разницы из-за чего так происходит. Можно было сделать нормально и с наследованием, можно было и без наследования сделать.
Только как хороший пример это вообще не подходит ни с какой стороны.
Re[40]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>2)Огласите правильный вариант, если знаете почему в asp.net core избегают наследования, в частности в middleware. НС>Фантастическое неуважение к собеседнику.
Ок, поправлюсь: огласите, пожалуйста, свое видение данного вопроса. Почему мое ошибочно?
S>>Судя по всему, ms. НС>О, опять пошли неуемные фантазии.
Какие же фантазии, когда мы тут видим цепочки наследования в wpf.
НС>>>О, то самое имаго за которое ты переживал. Я не говорил что наследования в UI нет, я говорил что его широкое распространение вызвано в основном историческими причинами, набором идеом которые зародились еще в TurboVision и расцвели пышным цветом в VCL. И винформсы прямой наследник VCL, того же автора. S>>Какие исторические причины у написанного с нуля wpf,
НС>Архитекторы, его проектировавшие — тоже с нуля? Люди не идеальны, у людей бэкграунд и инерция (ты вот сам был уверен, что для добавления чекбокса в грид наследование must have). Один из архитектов WPF, к примеру, заодно еще и архитектором SOAP был.
Раньше был не идеален и инерциален я. Теперь, оказывается, часть ms такая же. На счет с нуля -- на сколько понимаю да, писали с нуля,
имея перед глазами TurboVision и WinForms. И все равно удвоили показатели насследования. Опыт был, навыки были, ограничений на легаси
не было (с нуля же), а сделали так как сделали. Может быть дело в другом? Может стоит свою тз пересмотреть, а не всем остальным?
НС>Рассказать в каком месте сейчас SOAP и вообще идея OO-RPC?
Да, если не трудно? Чем grpc лучше\хуже OO-RPC?
S>> если там цепочки наследования чуть ли не удвоились НС>Неважно что там удвоилось. Важно что типичные кейсы, которые раньше требовали наследования, сейчас обходятся без них.
Важно, ибо, скорее всего, чтобы была такая гибкость, такая огромная цепочка наследования и должна быть. Одно тянет другое.
Кодом людям нужно помогать!
Re[41]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, karbofos42, Вы писали:
K>В итоге примерно так же как и в формах
В итоге совсем не так как в формах.
K>, в WPF тоже постоянно делаешь наследников и меняешь поведение.
Когда давно я занимался WPF что то там наследовать за пределами кодогенераторов приходилось крайне редко. И для изменения поведения тоже в большинстве случаев наследоваться не надо (всякие там триггеры, анимация etc как раз для этого и придуманы). Наследоваться надо, повторю, при необходимости изменения контракта. А учитывая что в нормально спроектированном UI лезть напрямую к контролам приходится редко, то и необходимость смены контракта, если ты, конечно, не работаешь в каком нибудь DevExpress, возникает нечасто.
K> Стилизацию контролов упростили и прочие мелочи.
Нет, не просто стилизацию. Вся отрисовка декларативна и не завязана на сам контрол. Есть отдельная сущность, display model, которую можно править не трогая контрол и от него не наследуясь.
Тоже самое с поведением. Визуальная реакция контрола на внешнее воздействие тоже в большинстве случаев описывается декларативно и является отдельно изменяемой без наследования сущностью.
Точно так же от контрола отделен и его стейт. Т.е. свойства контролов на самом деле данные не хранят, это просто мосты к dependency фреймворку, и можно эти совйства вообще не описывать в коде и контракте контрола, все и так будет работать, просто из кода к ним лезть придется несколько громоздким способом.
Наконец, намного более мощный и гибкий биндинг позволяет не лазать к контролам и их контрактам из кода, вместо этого взаимодействуя с данными напрямую. Соотв. и необходимости в правке контролов нет.
НС>>(ибо в C#, особенно в C# 2.0, актуальном на момент проектирования WPF альтернатив наследованию было совсем немного). K>А что появилось сейчас? Кодогенераторы, которые позволяют дублировать функционал без наследования?
В соседнем топике, к примеру, обсуждали traits. Да и обычные лямбды в ряде случаев позволяют сильно упростить дизайн.
НС>>И что? Почему это важно? K>Ну, не я тут пишу, что наследование плохо, виртуальные методы медленные и нужно всё делать иначе.
Можно ссылку где я писал что виртуальные методы медленные?
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[41]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>>>2)Огласите правильный вариант, если знаете почему в asp.net core избегают наследования, в частности в middleware. НС>>Фантастическое неуважение к собеседнику. S>Ок, поправлюсь: огласите, пожалуйста, свое видение данного вопроса. Почему мое ошибочно?
Неуважение твое заключается не в том что ты пожалуйста не написал, а в том что я тебе прямо написал почему сделано так, но ты то ли не читаешь, то ли с памятью у тебя серьезные проблемы.
S>>>Судя по всему, ms. НС>>О, опять пошли неуемные фантазии. S>Какие же фантазии, когда мы тут видим цепочки наследования в wpf.
Я тебе показал как МС решила описанную тобой задачу с чекбоксами в гриде. Цепочки наследования внутри фреймворка это отдельная история не особо на дизайн прикладных решений влияющая.
S>Раньше был не идеален и инерциален я. Теперь, оказывается, часть ms такая же.
Все такие. Welcome to real world.
НС>>Рассказать в каком месте сейчас SOAP и вообще идея OO-RPC? S>Да, если не трудно?
В жопе. Никому не нужно кроме легаси в энтерпрайзе.
S>Чем grpc лучше\хуже OO-RPC?
При чем тут grpc? grpc тоже с точки зрения дизайна — та еще какашка. Нормальное решение — http/REST.
НС>>Неважно что там удвоилось. Важно что типичные кейсы, которые раньше требовали наследования, сейчас обходятся без них. S>Важно, ибо, скорее всего, чтобы была такая гибкость, такая огромная цепочка наследования и должна быть.
Попробуй доказать сие предположение.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[42]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Ок, поправлюсь: огласите, пожалуйста, свое видение данного вопроса. Почему мое ошибочно? НС>Неуважение твое заключается не в том что ты пожалуйста не написал, а в том что я тебе прямо написал почему сделано так, но ты то ли не читаешь, то ли с памятью у тебя серьезные проблемы.
Дайте ссылку на объяснение, ибо я ничего такого не помню.
S>>Какие же фантазии, когда мы тут видим цепочки наследования в wpf. НС>Я тебе показал как МС решила описанную тобой задачу с чекбоксами в гриде. Цепочки наследования внутри фреймворка это отдельная история не особо на дизайн прикладных решений влияющая.
Надо понять, за счет чего такое решение работает. То, что там все разбито на компоненты,
которые легко заменить или кастомизировать, говорит, что с наследованием там все впорядке. Иначе
не было бы такой легкой заменяемости. Т.е. цепочки наследования как раз причем.
S>>Важно, ибо, скорее всего, чтобы была такая гибкость, такая огромная цепочка наследования и должна быть. НС>Попробуй доказать сие предположение.
Эт сложно. Но есть ощущение, подкрепляемое эмпирическими наблюдениями, что чем проще как-то кастомизировать
какой-либо компонент, тем длиннее у него цепочка наследований.
Кодом людям нужно помогать!
Re[43]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>С внимательностью у меня все отлично. Я цитату привел. Ты это прочел, а потом вдруг через несколько сообщений решил прицепиться к словам.
А, женская логика. Все, что не было оспорено немедленно, считается принятым (С)
Ад пуст, все бесы здесь.
Re[44]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
C>Абсолютные тоже важны, если они очень странные.
Забудь про них, ориентируйся на собственные. Результат это не меняет — switch ничуть не медленее виртуальных методов.
C>Так почему он у тебя в три раза медленнее?
Потому что железо другое.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[45]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Забудь про них, ориентируйся на собственные. Результат это не меняет — switch ничуть не медленее виртуальных методов.
Медленнее, хотя не радикально.
НС>Потому что железо другое.
Это не ответ. Специально проверил бенчмарк процессоров — твой должен быть медленнее только наполовину.
Ад пуст, все бесы здесь.
Re[20]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sinclair, Вы писали:
S>Допустим, вы хотите построить парсер некоторого DSL. Работать он будет, понятное дело, поверх некоторого StreamReader — хочется сделать его потоковым, и не зависеть от наличия в памяти всего разбираемого текста.
Твой DSL реально занимает гигабайты прамяти, или ты просто ищешь проблемы себе на кое какое место?
Ад пуст, все бесы здесь.
Re[21]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали: C>Твой DSL реально занимает гигабайты прамяти, или ты просто ищешь проблемы себе на кое какое место?
Нет, у меня просто аллергия на заведомо неудачные решения.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[22]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
C>А решение сэкономить микроскопическое количество памяти, чтобы поиметь кучу лишних проблем и просадить скорость на порядок — оно видимо очень удачное?
Скорость чего вы там собрались просаживать на порядок?
А рассуждения про "микроскопическое количество" вообще выглядят очень странно.
Речь идёт об асимптотике — O(logN) против O(N).
Язык на то и язык, что на нём бывает сложно заранее ограничить объём текста.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[24]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sinclair, Вы писали:
S>Скорость чего вы там собрались просаживать на порядок?
Не я, а ты. Скорость парсинга, естественно. Ты ведь надеюсь не думаешь, что все твои добавочные абстракции будут стоить так же дешево, как чтение символа из строки?
S>Язык на то и язык, что на нём бывает сложно заранее ограничить объём текста.
Ограничить объем прочитанного текста вообще не проблема, даже школьник должен справиться. Или тебе реально надо обрабатывать текст DSL на многие гигабайты? Я думаю, вряд ли.
Ад пуст, все бесы здесь.
Re[25]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
C>Не я, а ты. Скорость парсинга, естественно. Ты ведь надеюсь не думаешь, что все твои добавочные абстракции будут стоить так же дешево, как чтение символа из строки? Возьмётесь навскидку оценить стоимость "добавочных абстракций" в данном случае? Или опять будет как про сравнение switch с виртуальным вызовом?
C>Ограничить объем прочитанного текста вообще не проблема, даже школьник должен справиться. Или тебе реально надо обрабатывать текст DSL на многие гигабайты? Я думаю, вряд ли.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[26]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sinclair, Вы писали:
S> Возьмётесь навскидку оценить стоимость "добавочных абстракций" в данном случае?
Я уже оценил.
А ты сам не в состоянии оценить разницу между чтением символа из строки по его позиции, и иерархии из пары слоев абстракции со своими буферами и кучей добавочной логики?
S> Или опять будет как про сравнение switch с виртуальным вызовом?
А что тебя не устраивает?
S>
Слишком сложно?
Ад пуст, все бесы здесь.
Re[27]: почему в C# до сих пор нет наследования конструкторо
Здравствуйте, Codealot, Вы писали:
C>Я уже оценил. C>А ты сам не в состоянии оценить разницу между чтением символа из строки по его позиции, и иерархии из пары слоев абстракции со своими буферами и кучей добавочной логики?
Неа, у меня квалификации не хватает. Так, на глаз — разница будет пренебрежимо малой. Особенно если учесть стоимость самого парсинга. Иметь алгоритм, который на типичных объёмах кода будет работать за 2мс вместо 6ти, но падать на файле длиннее 2GB — ну, такое себе решение.
S>> Или опять будет как про сравнение switch с виртуальным вызовом?
C>А что тебя не устраивает? C>Слишком сложно?
То что разница в пределах статпогрешности объявлятся существенной.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Так, на глаз — разница будет пренебрежимо малой.
Ну тогда проверь глаза, потому что разница между чтением строки в памяти и StreamReader будет раз в 10 даже на предельно простом линейном чтении.
Кстати, а как ты вообще собрался реализовывать бактрекинг поверх ридера?
S>падать на файле длиннее 2GB
То есть ты таки настаиваешь, что тебе надо работать с DSL-ами в гигабайты размером?
S>То что разница в пределах статпогрешности объявлятся существенной.
Ты упустил самый главный момент — само по себе значение выглядит крайне странно, учитывая сравнительную скорость процессоров по универсальному бенчмарку.
Ад пуст, все бесы здесь.
Re[29]: почему в C# до сих пор нет наследования конструкторо
Здравствуйте, Codealot, Вы писали:
C>Ну тогда проверь глаза, потому что разница между чтением строки в памяти и StreamReader будет раз в 10 даже на предельно простом линейном чтении. C>Кстати, а как ты вообще собрался реализовывать бактрекинг поверх ридера?
Аккуратно
C>То есть ты таки настаиваешь, что тебе надо работать с DSL-ами в гигабайты размером?
Я настаиваю на том, что в требованиях не было ограничения на размер файлов. А также не было ограничения "работать только в однопользовательской среде".
Может быть, у меня данные едут по интернету, и я хочу, не забивая RAM на кэширование, уметь разбирать и обрабатывать их по мере поступления.
C>Ты упустил самый главный момент — само по себе значение выглядит крайне странно, учитывая сравнительную скорость процессоров по универсальному бенчмарку.
Не, не упустил. Ваше непонимание того, что "универсальный бенчмарк" измеряет быстродействие некоторой нагрузки, которая состоит из смеси разных команд, я отметил.
Но не счёл его заслуживающим отдельного ответа.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[30]: почему в C# до сих пор нет наследования конструкторо
Это не ответ. Рассказывай. А то мне кажется, что ни малейшей идеи как это сделать у тебя нет.
S>Я настаиваю на том, что в требованиях не было ограничения на размер файлов. А также не было ограничения "работать только в однопользовательской среде". S>Может быть, у меня данные едут по интернету, и я хочу, не забивая RAM на кэширование, уметь разбирать и обрабатывать их по мере поступления.
То есть ты настаиваешь на том, что память тебе крайне дорога, а вот на процессор тебе плевать.
S>"универсальный бенчмарк" измеряет быстродействие некоторой нагрузки, которая состоит из смеси разных команд, я отметил.
И что? С чего бы данной конкретной задаче настолько отличаться от смеси?
Впрочем, это все неважно. Кто-то там писал, что vtable — это дорого, и можно быстрее. Так что я все еще жду ответов, чем его можно заменить. Вариант "не знаю, зато у меня есть замена рефлекшену в некоторых случаях" не принимается.
Ад пуст, все бесы здесь.
Re[24]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sinclair, Вы писали:
C>>А решение сэкономить микроскопическое количество памяти, чтобы поиметь кучу лишних проблем и просадить скорость на порядок — оно видимо очень удачное? S>Скорость чего вы там собрались просаживать на порядок? S>А рассуждения про "микроскопическое количество" вообще выглядят очень странно. S>Речь идёт об асимптотике — O(logN) против O(N).
Где в этой задаче возникает такая асимптотика? Это про парсер?
Кодом людям нужно помогать!
Re[25]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>Где в этой задаче возникает такая асимптотика? Это про парсер?
Асимптотика расхода памяти. При разборе несложного формата расход памяти ~ глубине стека разбора.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[26]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sinclair, Вы писали:
S>>Где в этой задаче возникает такая асимптотика? Это про парсер? S>Асимптотика расхода памяти. При разборе несложного формата расход памяти ~ глубине стека разбора.
А из-за чего такая разница, то от чего мы наследуемся как-то влияет? TextReader vs StreamReader?
Кодом людям нужно помогать!
Re[27]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали: S>А из-за чего такая разница, то от чего мы наследуемся как-то влияет? TextReader vs StreamReader?
Нет, схема наследования не влияет. Рассуждения об асимптотике здесь только для того, чтобы как-то обосновать выбор TextReader вместо "просто строки".
Если мы выбираем "просто строку", то обязанность следить за номером строки/символа возлагается на сам парсер, и никого ни от кого наследовать не нужно.
Можно придумать и более простой пример, который будет меньше отвлекать внимание от основной задачи.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Codealot, Вы писали:
C>Судя по твоей попытке отмолчаться, делаю вывод, что до тебя наконец дошло, какую глупость ты понаписал.
Да, сначала я было подумал, что можно обойтись без бактрекинга, но понял, что не выйдет.
А ридер, увы, откатываться назад не умеет. Так что вы правы — я выбрал неудачный пример.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Ну, если проще — то пишите. Делов-то. Можно привести лошадь к воде, но вот пить её вы не заставите. 
.