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

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

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

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

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

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

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

НС>>Что угодно. Чем жирнее контракт, тем выше вероятность breaking changes
C>Только если он изначально плохо спроектирован.

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

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

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

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

НС>>Можно не велосипедить, а использовать тот же OrderBy.
C>А, то есть разбрасываемся оперативкой.

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

НС>>Удачной баньки.
C>Нарушаешь?

Я нет, ты — да.

НС>>Что нужно знать? Опять какие то обрывки смысла.
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 испаряется и ты получаешь исходный метод.

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

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

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

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

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

НС>>Ясно, ответа не будет. ЧТД.
C>Нет четкого описания требований — нет ответа.

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

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

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.

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

А то в шарпе более чем гибские способы управлять наследованием.

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

S>>>Внезапно мы про какой ЯП говорим?
НС>>Почему это важно?
S>Потому что в шарпе декоратор прежде всего через наследование реализуется.

Это утверждение нуждается в доказательстве.

S>>>Судя по тому, что там 2 класса которые мы декорируем, то наследование исп. 100% из 100%.
НС>>Я тебе рассказал как обойтись без него. В ч5м проблема?
S>А зачем

Чтобы продемонстрировать, что паттерн никуда не девается и не теряет своего смысла если наследование оттуда убрать.

S>>> На счет BikeParts хотелось бы подробностей, поскольку кажется, что именно через спискок BikeParts, обеспечивающий дин. изм. поведения, как раз
S>>>мало кто делает.
НС>>То что тебе кажется это не аргумент.
S>Это и в обратную сторону работает.

Работает. Вот только я не пишу что мне что то там кажется.

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

S>>Потому что в шарпе декоратор прежде всего через наследование реализуется.
НС>Это утверждение нуждается в доказательстве.

Доказательство от противного -- без наследования классов или интерфейса в шарпе,
я не видел ни одной реализации паттерна декоратор.


S>>>>Судя по тому, что там 2 класса которые мы декорируем, то наследование исп. 100% из 100%.
НС>>>Я тебе рассказал как обойтись без него. В ч5м проблема?
S>>А зачем
НС>Чтобы продемонстрировать, что паттерн никуда не девается и не теряет своего смысла если наследование оттуда убрать.

Ну так продемонтстрируйте кодом, если знаете как. В чем проблема?

S>>Это и в обратную сторону работает.
НС>Работает. Вот только я не пишу что мне что то там кажется.

Покажите, код и всех делов.

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

S>Доказательство от противного -- без наследования классов или интерфейса в шарпе,

Интерфейс не наследуется, он реализуется.

S>я не видел ни одной реализации паттерна декоратор.

Ну мало ли чего ты не видел.


НС>>Чтобы продемонстрировать, что паттерн никуда не девается и не теряет своего смысла если наследование оттуда убрать.
S>Ну так продемонтстрируйте кодом, если знаете как. В чем проблема?

70 баксов в час и никаких проблем. А бесплатно придется тебе напрячься и понять написаное без готового кода.

НС>>Работает. Вот только я не пишу что мне что то там кажется.
S>Покажите, код и всех делов.

70 баксов в час и всех делов

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

S>>Доказательство от противного -- без наследования классов или интерфейса в шарпе,
НС>Интерфейс не наследуется, он реализуется.

Тем более.

S>>я не видел ни одной реализации паттерна декоратор.
НС>Ну мало ли чего ты не видел.



S>>Ну так продемонтстрируйте кодом, если знаете как. В чем проблема?
НС>70 баксов в час и никаких проблем. А бесплатно придется тебе напрячься и понять написаное без готового кода.

Ожидаемо. Что же там такого надо делать, что это час займет? Или час займет поиск в гугле соовт. реализаци, если она есть, конечно?

S>>Покажите, код и всех делов.
НС>70 баксов в час и всех делов

Ожидаемо

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

S>>>Доказательство от противного -- без наследования классов или интерфейса в шарпе,
НС>>Интерфейс не наследуется, он реализуется.
S>Тем более.

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

S>>>Ну так продемонтстрируйте кодом, если знаете как. В чем проблема?
НС>>70 баксов в час и никаких проблем. А бесплатно придется тебе напрячься и понять написаное без готового кода.
S>Ожидаемо. Что же там такого надо делать, что это час займет?

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

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

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

Классика! Был тезис:

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

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

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

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

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

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

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

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

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

S>Незачем курочить компилятор, когда то же самое можно сделать через набор библиотек

А зачем record добавили?

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

S>>Незачем курочить компилятор, когда то же самое можно сделать через набор библиотек
K>А зачем record добавили?

Потому что record нельзя сделать через набор библиотек.

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

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

Я подозреваю, что речь идёт о том, что нужно классы реализовывать с оглядкой на их возможное расширение.
Не описал методы как virtual, не подготовил интерфейс — поимеешь проблемы.
Если это свои классы, то ещё можно их переделать, но может сломаться старый функционал.
С библиотечными классами будешь в пролёте, т.к. всё везде sealed, никакой виртуализации и т.п.
Захочешь в WPF класс MessageBox под себя подправить — делай свой с нуля, т.к. всё закрыто.

Здравствуйте, 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; } }

Здравствуйте, 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.
Чего они язык то меняют ради плюшек каких-то, пусть все кодогенераторы прикручивают?

Здравствуйте, 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 реализовать через дополняющую кодогенерацию вообще никак невозможно, ни красиво, ни коряво.