Здравствуйте, 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>Это как?
Во время выполнения решается какой метод вызовется, в зависимости от типа объекта.
Сконцентрируйся на языке, не надо сюда тащить всякий новомодный мусор, да ещё придумывать на ходу "всё обрастает дикими костылями". А ЧТО Б* ЕСЛИ НЕТ?? (ц) Слепаков
