Здравствуйте, 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/
Незачем курочить компилятор, когда то же самое можно сделать через набор библиотек
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
, при этом если я явно реализовал ctor соотв. сигнатуре какого-то базового ctor, то использовать его. Прозрачно это могло бы быть сделано на уровне компилятора, наподобие генерации тела авто-пропертей.
