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

S>Ну, совсем-то обязательного вовсе ничего нет.

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

S>Вот с конструкторами разницы в навешивании атрибута и навешивании нового ключевого слова практически нет (1 лишний keyword — partial, да и тот можно добавить батч-авто-фиксером).

Ну, ещё очень удобно наверно искать реализацию вызываемого конструктора, когда Go to Definition будет отправлять в пустой сгенерированный конструктор, а оттуда в следующий и т.д.?

S>А, скажем, static virtual interface methods или generic math реализовать через дополняющую кодогенерацию вообще никак невозможно, ни красиво, ни коряво.

Костыли какие-то приделывают, а вот именно наследование конструкторов — это что-то ужасное, что испортит язык, что такому здесь не место.
Ещё можно вспомнить реализацию методов в интерфейсах. Такие методы "наследовать" можно и никаких проблем, а вот конструкторы — это всё от лукавого.

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

S>>Т.е нужен фрагмент кода, который подтверждал бы Ваш тезис, и невозможность как-то его изменить, что подтверждало бы
S>>тезис про ненастраиваемость. В ответ -- уход от темы про способы реализации декоратора, и прочая обычная для Вас кака-бяка.

S>Ну вот смотрите, какая штука.
S>Допустим, вы хотите построить парсер некоторого DSL. Работать он будет, понятное дело, поверх некоторого StreamReader — хочется сделать его потоковым, и не зависеть от наличия в памяти всего разбираемого текста.
S>И вот вам захотелось иметь возможность репортить ошибки с привязкой к строка/позиция, а не просто "character #2213123".
S>Как вы это будете делать? Отнаследуетесь от SteamReader? Отнаследуетесь от TextReader? Сделаете свой класс, не отнаследованный ни от чего?
S>Какие методы придётся перекрыть? Какие — не придётся?

Скорее всего унаследуюсь от TR, но агрегирую SR, ибо надо позицию учитывать. Как-то так.

S>Это простое упражнение помогает прояснить различия между агрегацией, наследованием реализации, и наследованием интерфейса.

Мне казалось, я эту разницу понимаю.

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

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

S>>Настраиваемая связь -- это паттерн декоратор, если virtual, override или new не хватает.
S>>Гибкость связи: override -- привязываем к родителю, new -- отвязываем от родителя. Что может быть гибче?

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

Так НС же не говорит, что конкретно не так. Общие фразы, без конкретики. Я привел возможные способы решения,
разговор ушел куда-то не туда.

K>Не описал методы как virtual, не подготовил интерфейс — поимеешь проблемы.
K>Если это свои классы, то ещё можно их переделать, но может сломаться старый функционал.

Кривой дизайн и арх-ру язык не поправит. Он не для этого. А придать гибкости и настраиваемости -- пожалуйста.

K>С библиотечными классами будешь в пролёте, т.к. всё везде sealed, никакой виртуализации и т.п.

Ну значит не судьба, что тут поделаешь.

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

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

K>Или именно эту фичу обязательно через изменение языка и добавление ключевого слова реализовывать?
Какую "эту"? Я что-то уже потерялся.

K>Ну, ещё очень удобно наверно искать реализацию вызываемого конструктора, когда Go to Definition будет отправлять в пустой сгенерированный конструктор, а оттуда в следующий и т.д.?
Ну да, всё верно. А что не так? Или вы хотели, чтобы навигация прыгала сразу в конструктор предка? А если он вручную выписан тоже как :base(...) {}?
K>Костыли какие-то приделывают, а вот именно наследование конструкторов — это что-то ужасное, что испортит язык, что такому здесь не место.
Да почему испортит то?
В общем, я вас не понимаю. Двум людям на этом форуме вроде как нужна фича, которая позволяет не писать однообразные конструкторы.
Вам её дали — и опять что-то не нравится.

K>Ещё можно вспомнить реализацию методов в интерфейсах. Такие методы "наследовать" можно и никаких проблем, а вот конструкторы — это всё от лукавого.
Можно. Проблема у вас в чём? Как должна выглядеть фича про конструкторы, чтобы вас она устроила?

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

S>Я вам дал ссылку на наследование конструкторов при помощи атрибута. Что не так-то?

Что это криво работающая сторонняя примочка, а не стандартная возможность

S>Какую "эту"? Я что-то уже потерялся.

наследование конструкторов.

S>Ну да, всё верно. А что не так? Или вы хотели, чтобы навигация прыгала сразу в конструктор предка? А если он вручную выписан тоже как :base(...) {}?

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

S>Да почему испортит то?

Если она не портит язык, то почему её не добавить?

S>В общем, я вас не понимаю. Двум людям на этом форуме вроде как нужна фича, которая позволяет не писать однообразные конструкторы.
S>Вам её дали — и опять что-то не нравится.

Кривое решение, что в итоге проще и надёжнее ручками продолжить писать конструкторы.

S>Можно. Проблема у вас в чём? Как должна выглядеть фича про конструкторы, чтобы вас она устроила?

Фича должна выглядеть как что-то стандартное, для чего не нужно добавлять зависимости, создавать partial классы, танцевать с бубном и т.п.

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

S>Скорее всего унаследуюсь от TR, но агрегирую SR, ибо надо позицию учитывать. Как-то так.
Ну, агрегировать (декорировать) надо скорее TextReader, потому что иначе у вас не будет возможности применить ваши наработки к альтернативным наследникам (например, StringReader).
S>>Это простое упражнение помогает прояснить различия между агрегацией, наследованием реализации, и наследованием интерфейса.

S>Мне казалось, я эту разницу понимаю.
Ну, вот как раз тут и начинаются всякие интересные приплызды. Скажем, невозможно не отнаследоваться от TextReader — не существует интерфейса, который можно было бы реализовать при помощи прямого потомка object.
TextReader тащит за собой довольно-таки толстую реализацию, отказаться от которой вы не можете. Ещё в нём есть всякие неочевидные зависимости — повторюсь: какие методы вы будете перекрывать? Сможете сказать, не глядя в исходники? Как там с асинхронщиной — будет унаследованная реализация вам помогать или мешать? Может быть, вам захочется запретить асинхронное использование вашего декоратора — ан нет, нельзя, нет такого способа.

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

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

K>Что это криво работающая сторонняя примочка, а не стандартная возможность
Что-то конкретное не устраивает? Вы расскажите, мне интересен опыт использования из первых рук.

K>Если она не портит язык, то почему её не добавить?
А если портит?

K>Кривое решение, что в итоге проще и надёжнее ручками продолжить писать конструкторы.
Ну, если проще — то пишите. Делов-то. Можно привести лошадь к воде, но вот пить её вы не заставите.

K>Фича должна выглядеть как что-то стандартное, для чего не нужно добавлять зависимости, создавать partial классы, танцевать с бубном и т.п.
Ок, пошли капризы. В общем, я понял — ехать вам не надо, надо шашечки.
На этом беседу можно сворачивать.

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

S>Что-то конкретное не устраивает? Вы расскажите, мне интересен опыт использования из первых рук.

Так я написал что не устраивает или повторить нужно?

S>А если портит?

Определитесь уже портит или не портит

S> Ну, если проще — то пишите. Делов-то. Можно привести лошадь к воде, но вот пить её вы не заставите.

Ну, вот до появления record, использовались какие-то кодогенераторы для получения подобного результата?
Или ручками писались всякие DTO и вроде нормально было?

S>Ок, пошли капризы. В общем, я понял — ехать вам не надо, надо шашечки.

Мне ехать на нормальном рабочем решении, а не на костылях сомнительного качества, не дающих при этом практически никакого удобства.

S>На этом беседу можно сворачивать.

Эта тема не имеет смысла уже давно, т.к. вместо ответов на вопрос какие-то пространные рассуждения.

Здравствуйте, karbofos42, Вы писали:
K>Так я написал что не устраивает или повторить нужно?
Вы не написали, что значит "криво". Какой именно случай непокрыт или покрыт неверно? У меня есть гипотезы, но ваши приоритеты гораздо важнее — мне-то такая фича вовсе не нужна. Это у вас есть какие-то сценарии, в которых такое автопорождение может быть полезным. Я про них ничего не знаю.

K>Определитесь уже портит или не портит
Тут всё просто. Смотрите: автонаследование без ключевого слова — сразу нет. Это резко поломает обратную совместимость большого количества кода, работающего в проде.
Автонаследование с ключевым словом — ну, так. Без реальной практики использования есть множество интересных вопросов про то, как это должно работать. То ли наследуем все конструкторы, то ли только помеченные специальным словом.
То ли наоборот тащим все, кроме помеченных специальным словом. То ли мы должны пометить спецсловом предка, то ли потомка, то ли обоих сразу.
Когда мы запекаем такую штуку в языке — всё, обратного хода нет. Библиотека позволяет каждому вташить в проект своё представление о прекрасном, никак не навязывая его всему остальному человечеству.
Если когда-то сложится консенсус по поводу фичи — можно и в язык её втащить. Точно так же, как магические атрибуты компилятора и рантайма.
Я бы при возможности голосовал за ещё большее перетаскивание языка в библиотеки — ну, как с теми же генераторами стейт-машин для асинков, или интерполяторами строк.
С нетерпением ждём переноса порождения Expression Trees из компилятора в библиотеки — это позволит куда как гибче и точнее обрабатывать выражения в нужных нам местах.

K>Ну, вот до появления record, использовались какие-то кодогенераторы для получения подобного результата?
До появления record source generator-ов не было.
K>Или ручками писались всякие DTO и вроде нормально было?
Но да, те, кому было лень руками выписывать DTO, пользовались T4 и прочими генераторами API по схеме.
S>>Ок, пошли капризы. В общем, я понял — ехать вам не надо, надо шашечки.
K>Мне ехать на нормальном рабочем решении, а не на костылях сомнительного качества, не дающих при этом практически никакого удобства.
По-прежнему непонятно, какого именно удобства вам не хватает.

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

K>>С библиотечными классами будешь в пролёте, т.к. всё везде sealed, никакой виртуализации и т.п.
S>Ну значит не судьба, что тут поделаешь.

Это не судьба, это реальное свойство реальной технологии. Когда в учебниках и на модельных примерах все круто, а на практике получается больше проблем, чем пользы. Посмотри, к примеру, на дизайн Asp.Net Core — там и изначально то было немного наследования, меньше чем в прародителе, а со временем наследования там становится все меньше и меньше. Даже в очевидных вроде бы местах типа миддлверов, где, казалось бы, сам бог велел использовать какой нибудь базовый Middleware, на самом деле такого класса/интерфейса нет.
Или давай на ORM глянем — необходимость со стороны ORM наследовать классы модели от базового класса не заклеймил только ленивый.
Вообще, много можешь в .NET назвать относительно свежих API, где присутствует необходимость наследования от базового класса?

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

НС>Чтобы продемострировать, почему одновременное и неразрываемое наследование и контракта и реализации это плохо.

Есть еще абстрактные классы. Не слышал?

НС>https://henrietteharmse.com/2015/04/18/the-rectanglesquare-controversy/

Там нет ответа, зачем это может быть нужно на практике. Задача из разряда "сколько ангелов может поместиться на кончике иглы".

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

S>Так что если вам нужно массовое наследование конструкторов — велком.

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

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

НС>Тенм лучше для всенх. При условии, разумеется, соответствия известным юзкейсам.

Знакомое оправдание Еще можешь использовать "это для вашего же блага".

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

НС>Это иллюзия, что можно так спроектировать что потом менять не придется.

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

НС>Нет. Если велосипедирование причиняет боль или приводит к ошибкам — это отличный повод для изменений.

Ага, серийный программист Джон.

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

НС>Ты уж определись, нужен тебе перфоманс или нет.

В данном случае, выделение добавочной оперативки — результат одной только лени. Так что твое предложение — никудышное.

НС>Какой термин?

Никто не может быть настолько тупым. Я думаю, ты прекрасно понял какой.

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

R>required не про это, required про то, что поле/свойство необходимо инициализировать при создании, и компилятор не даст тебе это забыть или проигнорировать. Для баланса, так сказать, для тех кто не хочет по тем или иным причинам использовать конструктор, но нужно, чтобы свойство было проинициализировано.

Но потом все равно можно поменять. Странно, не?

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

S>Поэтому как ни крутись, а синтаксис record Person(string Firstname, string Lastname); через них не получишь.

А оно вообще сильно надо?

Здравствуйте, Codealot, Вы писали:
C>Но потом все равно можно поменять. Странно, не?
Как по мне — так нет. Мутабельность ортогональна обязательности.
Мы же при изменениях всё контролируем — если нам нужно значение, удовлетворяющее какому-то сложному предикату, то мы это в сеттере проверим.
Остаётся только один способ пронести невалидное значение в объект — дефолт при конструировании. Вот, reqiured эту дырку закрывает.

А иммутабельность как была, так и осталась через readonly или init-only.

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

S>Как по мне — так нет. Мутабельность ортогональна обязательности.

Мда? То есть неизменяемое поле может быть необязательным?

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

K>Здравствуйте, Baiker, Вы писали:
B>>Что в C# налажали, так это вызов самих конструкторов. Если я правильно ошибаюсь, в Delphi можно вызывать базовый конструктор из любого места текущего конструктора. В C# это возможно только в начале.

K>И зачем эта фича нужна?
K>Какие-то минимальные расчёты можно и в текущем варианте передать в вызове base.

А ты не думал, что конструкторов может быть несколько?? И какой из них вызывать и решают расчёты.

K>Если там какая-то сложная логика, то вообще странно в конструктор это пихать.

С чего бы "странно"?? Где удобно — там и делаю.

K>Тут уже какая-нибудь фабрика нужна, которая и асинхронность сможет предоставить.

Код — рабочим, фабрики — молодым клоунам-рассуждателям об ИТ. Не надо захламлять и без того сложные системы своими безумными Gang Of Fools.