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

S>>Никакой библиотеки для его реализации не надо, только наследование и конструктор с параметром.
S>>Т.е. средствами ЯП.
P>Паттерн == библиотечный способ реализации фичи. Встроеный в язык — когда есть фича, например такая
P>

P>decorator class Widget {  
P> // например каким то способом ограничиваем расширение интерфейса, и гарантируем только изменение поведения публичных методов.
P>}
P>

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



S>>Ничего не понял, если честно.
P>Ожидаемо. Есть книга Бертрана Мейера Объектно ориентированое проектирование, кажется так. В неё подробно говорится о том, что же такое ооп.

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

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

S>>Разрывает cлишком сильную связность между предком и наследником.
P>Разрывает как раз декоратор, стратегия, а не слово new. В некоторых языках никакого new не требуется, просто вызываешь конструктор по имени класса напрямую.
P>Параметр у new — та самая реализация, где и предок, и наследник прибиты гвоздями друг к другу.

Мы точно говорим об одном и том же, т.к. я говорю об этом -- https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/new-modifier ?

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

S>Для меня библиотечный это именно, что подключать что-то извне, библиотеку какую-нибудь, пусть даже самую базовую.
S>Тут же ничего такого не надо, а просто несколько строк на самом языке. Ок, это терм. спор.

Библиотека это совсем необязательно чтото, что надо подключать извне. Это может быть твоя собственная библиотека прямо в соседнем фолдере или даже просто в соседнем файле.
Декораторы обычно являются такой библиотекой — на разные объекты навешиваем комбинации самых разных декораторов.

S>>>Ничего не понял, если честно.
P>>Ожидаемо. Есть книга Бертрана Мейера Объектно ориентированое проектирование, кажется так. В неё подробно говорится о том, что же такое ооп.

S>Книга эта есть, даже читал большую часть лет 10 назад. Но к чему был тот комментарий "за все хорошее против всего плохо" в контексте

Я описал проблему, откуда она растет. Класс это два кейса в одном — и тип, и модуль, см эту самую книгу. И наследование, соответственно, тоже два кейса в одном — и уточнение типа, и расширение модуля. Отсюда ясно, что обозначеная проблема в нынешних реализациях ООП неустранима, принципиально.
Вот скажем, если разделить subtype и extends, вроде бы круто, но я вот не сильно уверен, что на таком языке можно будет хоть что нибудь писать, т.к. такое смешение дает чудовищно мощный инструмент.

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

S>Мы точно говорим об одном и том же, т.к. я говорю об этом -- https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/new-modifier ?

Да, не посмотрел. Это просто пере-резервирование имени. Все проблемы, которые были, до единой, остались, хоть обнаследуйся с new.

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

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.

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


P>Библиотека это совсем необязательно чтото, что надо подключать извне. Это может быть твоя собственная библиотека прямо в соседнем фолдере или даже просто в соседнем файле.
P>Декораторы обычно являются такой библиотекой — на разные объекты навешиваем комбинации самых разных декораторов.

Я не считаю библиотекой, тем более декораторы, то, что пишется на самом языке в две строчки -- унаследовались
и передали в конструктор параметры. Какие фолдеры и соседние файлы? Оперирую базовыми сущностями языка.


S>>Книга эта есть, даже читал большую часть лет 10 назад. Но к чему был тот комментарий "за все хорошее против всего плохо" в контексте
P>Я описал проблему, откуда она растет. Класс это два кейса в одном — и тип, и модуль, см эту самую книгу. И наследование, соответственно, тоже два кейса в одном — и уточнение типа, и расширение модуля. Отсюда ясно, что обозначеная проблема в нынешних реализациях ООП неустранима, принципиально.
P>Вот скажем, если разделить subtype и extends, вроде бы круто, но я вот не сильно уверен, что на таком языке можно будет хоть что нибудь писать, т.к. такое смешение дает чудовищно мощный инструмент.

В шарпе есть как наследование, так и extension methods (т.е. extends). Можем специфицировать, можем
расширить. Опять же, для extends можно декоратор использовать.

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

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

Хоть одну, это всё равно библиотечный спосою. Выделенной фичи для декораторов нет. Для наследования — есть, для классов — есть, для интерфейсов — тоже.
Всего два варианта — или выделеная фича, или её отсутствие

P>>Вот скажем, если разделить subtype и extends, вроде бы круто, но я вот не сильно уверен, что на таком языке можно будет хоть что нибудь писать, т.к. такое смешение дает чудовищно мощный инструмент.

S>В шарпе есть как наследование, так и extension methods (т.е. extends). Можем специфицировать, можем

Методы-расширения это круто. Только реализация наследования в C# от этого не меняется.

S>Опять же, для extends можно декоратор использовать.

Тогда нарушается основной признак декоратора. Декоратор он до тех пор декоратор, пока сохраняет базовый интерфейс. Это свойство позволяет комбинировать декораторы как попало.

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

НС>Я его проектирую по принципу — не делать вещей для которых нет известных use cases.

То есть чем меньше, тем лучше для тебя.

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

НС>Можно не велосипедить, а использовать тот же OrderBy.

А, то есть разбрасываемся оперативкой.

НС>Удачной баньки.

Нарушаешь?

НС>Что нужно знать? Опять какие то обрывки смысла.

Не в состоянии погуглить термин, раз уж ты его не знаешь?

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

НС>Нет. Я объяснил почему другая.

Не объяснил.

НС>Нет.

Ушел в глухую несознанку.

НС>Удобно, все что не подходит под теорию объявить высосанным из пальца.

Объясни, зачем конкретно тебе это надо — тогда и можно будет решить, что не высосано.

НС>Ясно, ответа не будет. ЧТД.

Нет четкого описания требований — нет ответа. А ты надеялся описать все как можно более невнятно и потом манипулировать требованиями? Не выйдет.

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

НС>Что угодно. Чем жирнее контракт, тем выше вероятность breaking changes

Только если он изначально плохо спроектирован.

НС>Если будут сами — будет известный и понятный юзкейс, под который можно вменяемо доработать public API.

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

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

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

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

Покажешь как?

public class Person
{
  public required string Name { get; init; }
  public required string LastName { get; init; }
}

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

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

В общем, вот: https://www.nuget.org/packages/Constructor.Inheritor/

На страничке пакета всё, что нужно, написано.

1. Добавляете этот пакет в зависимости своего проекта
   
2. Помечаете нужные вам классы атрибутом [InheritConstructors]
   
3. PROFIT!!!

Если шаг 1 делаете из студии, то её придётся перезапустить. Я пока не понял, как сделать так, чтобы при регистрации нового SourceGenerator/Analyzer остальные анализаторы не сворачивались трубочкой.

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

R>Покажешь как?

        class TestClass
        {
            public required int Field1;
        }

        var obj = new TestClass { Field1 = 1, };
        obj.Field1 = 2;

Регулярно задаюсь вопросом, каким местом они думают. Но, видимо, не головой.

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

S>Мне и нескольким довольно опытным коллегам запрошенная вами возможность представляется избыточной.

Это те, которые пишут крайне странные вещи про метаданные базовых классов и наследование? Вижу, какой там "опыт".

S>Я пока не понял, как сделать так, чтобы при регистрации нового SourceGenerator/Analyzer остальные анализаторы не сворачивались трубочкой.

А, всего лишь

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

C>есть внятные объяснения?

В общем случае класс-наследник определяет как именно конструировать его родителя — т.к. он знает чего он от родителя хочет. Родитель может иметь 5 конструкторов, а наследник — всего один конструктор. Если бы "наследование конструкторов" работало, всего у наследника было бы 6 конструкторов, из которых "адекватный" только один. Если вызвать один из родительских конструкторов, как именно наследническая часть должна инициализироваться? Мне кажется, что как оно сейчас сделано — это логично и предсказуемо.

Здравствуйте, Codealot, Вы писали:
S>>Я пока не понял, как сделать так, чтобы при регистрации нового SourceGenerator/Analyzer остальные анализаторы не сворачивались трубочкой.
C>А, всего лишь
Я так понимаю, это какая-то известная проблема. Но после перезапуска студии она пропадает.
Так что если вам нужно массовое наследование конструкторов — велком.

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

R>Если бы "наследование конструкторов" работало, всего у наследника было бы 6 конструкторов, из которых "адекватный" только один. Если вызвать один из родительских конструкторов, как именно наследническая часть должна инициализироваться? Мне кажется, что как оно сейчас сделано — это логично и предсказуемо.

Если "наследовать" все базовые ctors неявно, то конечно это неюзабельно, и вряд-ли это будет когда-либо сделано. А вот явно указать, что хочешь "наследовать" все базовые ctors, наподобие как в C++ (тут пример показали

Автор: karbofos42
Дата: 25.11.22

), то почему бы и нет? Ну вот надо мне , при этом если я явно реализовал ctor соотв. сигнатуре какого-то базового ctor, то использовать его. Прозрачно это могло бы быть сделано на уровне компилятора, наподобие генерации тела авто-пропертей.

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


C>Регулярно задаюсь вопросом, каким местом они думают. Но, видимо, не головой.
Эмм. Налицо какая-то путаница. В исходной даденой вам ссылке опечатка: required не имеет отношения к обсуждаемому вопросу. Речь про init-only properties:

    class TestClass
        {
            public int Prop1{ get; init;} 
        }

        var obj = new TestClass { Field1 = 1, };
        obj.Prop1= 2;

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

_>Если "наследовать" все базовые ctors неявно, то конечно это неюзабельно, и вряд-ли это будет когда-либо сделано. А вот явно указать, что хочешь "наследовать" все базовые ctors, наподобие как в C++ (тут пример показали

Автор: karbofos42
Дата: 25.11.22

), то почему бы и нет? Ну вот надо мне , при этом если я явно реализовал ctor соотв. сигнатуре какого-то базового ctor, то использовать его. Прозрачно это могло бы быть сделано на уровне компилятора, наподобие генерации тела авто-пропертей.
Повторюсь, https://www.nuget.org/packages/Constructor.Inheritor/
Незачем курочить компилятор, когда то же самое можно сделать через набор библиотек