Здравствуйте, Ночной Смотрящий, Вы писали:
S>> generator.Emit(OpCodes.Callvirt, realMethod); НС>Callvirt может использоваться для вызова невиртуальных методов, ровно как Call — для вызова виртуальных. Callvirt в данном контексте более универсален, поэтому его и используют. А реальный вызов, виртуальный или нет, генерирует JIT. И если в аргументе будет невиртуальный метод — никакого виртуального вызова не будет.
Ну и в чем тогда смысл оптимизации, если ключеое слово "если". А если будет виртуальный метод, то в чем смысл оптимизации?
Я выше привел цитату для чего этот код нужен:
In previous versions of System.Text.Json, the serializer always used Reflection.Emit where possible to generate fast member accessors to constructors, properties, and fields. Generating these IL methods takes a non-trivial amount of time, but also consumes private memory. With source generators, we are able to generate code that that statically invokes these accessors. This eliminates time and allocation cost due to reflection.
Но где там про виртуальные методы и их замену генерацией кода?
Кодом людям нужно помогать!
Re[30]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Не смогу, поскольку не до конца понимаю, что надо. НС>
По каким-то сообржениям, скорее производительности, решили не связываться с абстрактным middleware
и абстрактными методами, заменив их на интерфейс. Для DI будет проще.
S>>UI фреймворк, очевидно, типа WinForms. Почему-то все формы надо от Form наследовать. НС>И что в этом хорошего? Почему в ASP.NET не надо контроллеры от одного объекта наследовать?
А что плохого? Зачем сравнивать холодное с мягким -- развесистый UI и контроллер, задачи которого брать
данные из модели и передавать во view(или обратно) + всяческая bl. А сколько всего навешано для работы грида, и каждый
раз писать заново или копипаста, да еще сохранить совместимость, т.е. там где ждуть тип Grid, наш самодельный
грид также должен подходить. В общем, не вижу альтернативы наследованию.
Кодом людям нужно помогать!
Re[39]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали: НС>Это самый натуральный полиморфизм, обеспечивающий полиморфное поведение и скорость равносильную статическим вызовам. Есть еще статический полиморфизм, когда полный набор форм известене на этапе компиляции. В дотнете такое можно изобразить при помощи перегрузки функций или операторов. Есть еще параметрический полиморфизм, в дотнете представленный дженериками. Нам его базе есть интересные фокусы с использованием того факта, что статические поля дженерик класса для каждого дженерик параметра свои. Наконец, в свеженьком шарпе есть static virtual, который в рантайме не порождает виртуального вызова с адресацией через vtbl, а так же опирается на кодогенерацию дженериков JITом.
Кстати, там пока что на мой вкус всё довольно сыренько.
Самое весёлое — это наличие "скрытых" статических методов в классе.
Если мы делаем явную реализацию экземплярного метода, то до него можно добраться путём каста экземпляра к интерфейсу:
public interface IFoo
{
void Foo();
}
public class Foo: IFoo
{
void IFoo.Foo()=> Console.WriteLine("Foo!");
}
...
var foo = new Foo();
foo.Foo(); // doesn't compile
((IFoo)foo).Foo(); // ok
А вот если у нас аналогичным образом реализован static virtual, то кабзда. Его можно вызвать только в generic-контексте, т.к. приводить к интерфейсу нечего.
К примеру — попробоуйте вызвать TryReadBigEndian для типа short или int.
Здравствуйте, Sharov, Вы писали:
S>>>Не смогу, поскольку не до конца понимаю, что надо. НС>> S>По каким-то сообржениям, скорее производительности, решили не связываться с абстрактным middleware S>и абстрактными методами, заменив их на интерфейс. Для DI будет проще.
Т.е. ты нифига не знаешь, высасываешь из пальца какой то ничем необоснованный бред про производительность, а потом еще и споришь с теми кто знает. Поэтому
S>>>UI фреймворк, очевидно, типа WinForms. Почему-то все формы надо от Form наследовать. НС>>И что в этом хорошего? Почему в ASP.NET не надо контроллеры от одного объекта наследовать? S>А что плохого?
Лишние ограничения на дизайн, лишняя связность.
S>Зачем сравнивать холодное с мягким -- развесистый UI и контроллер
Затем что они решают похожие задачи.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[40]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sinclair, Вы писали:
S>Его можно вызвать только в generic-контексте
Да. Он для этого и придуман — обеспечить перегрузку операторов и методов по дженерик-параметру. Таким образом ты можешь получить вызов разных статических методов в зависимости от параметра, единожды написав дженерик код. Основной юзкейс — дженерик-арифметика для числомолотилок.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[41]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Да. Он для этого и придуман — обеспечить перегрузку операторов и методов по дженерик-параметру. Таким образом ты можешь получить вызов разных статических методов в зависимости от параметра, единожды написав дженерик код. Основной юзкейс — дженерик-арифметика для числомолотилок.
Ну, это понятно. Непонятно, по большому счёту, почему я не могу вызвать этот метод для конкретного типа.
Я понимаю, что, скажем, TryParse я теперь могу вызывать не на конкретном int или long, а на любом T, который реализует IParsable<T>. Но давать методы, которые доступны только в generic-контексте, странно
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[37]: почему в C# до сих пор нет наследования конструкторов?
| Method | Mean | Error | StdDev |
|-------- |---------:|---------:|---------:|
| Virtual | 67.88 us | 0.158 us | 0.148 us |
| Switch | 70.84 us | 0.093 us | 0.087 us |
Подтасовываешь данные в надежде, что я не стану проверять?
Ад пуст, все бесы здесь.
Re[39]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это самый натуральный полиморфизм, обеспечивающий полиморфное поведение и скорость равносильную статическим вызовам.
Это не имеет никакого отношения к виртуальным методам, о которых шла речь. От слова вообще.
Ад пуст, все бесы здесь.
Re[32]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>По каким-то сообржениям, скорее производительности, решили не связываться с абстрактным middleware S>>и абстрактными методами, заменив их на интерфейс. Для DI будет проще. НС>Т.е. ты нифига не знаешь, высасываешь из пальца какой то ничем необоснованный бред про производительность, а потом еще и споришь с теми кто знает. Поэтому
Ну-ну-ну, я пытался ответить на вопрос, почему в asp .net core (и вообще asp.net), они решили обойтись
интерфейсом, а не наследованием. Дескать, из-за наследования будет лишний оверхед в виде vt.
Почему-то обосновать что это "необоснованный бред" никто пока не смог. В ответ ор, кака-бяка и переход
на личности. Т.е. вместо того, чтобы дать ответь, если он есть, идет ходьба вокруг да около.
S>>А что плохого? НС>Лишние ограничения на дизайн, лишняя связность.
Так может для UI это хорошо? Там куча кода для тех же гридов и проч. контролов, и все
это предлагается убрать за интерфейс и писать с нуля? Или через композицию, где будет
куча методов типа
class NewGrid: IGrid
{
....
private readonly Grid _oldGrid;
public void Redraw(){
_oldGrid.Redraw()
}
...
}
И все это, чтобы поменять две-три строчки метода в одном-двух методах. Ну такое себе.
Наследование здесь явно выигрывает и лишняя связность тут явно к месту.
S>>Зачем сравнивать холодное с мягким -- развесистый UI и контроллер НС>Затем что они решают похожие задачи.
Ну не сказал бы -- Forms это больше UI+контроллер (причем, скороее UI), а asp .net контроллер, внезапно, просто
контроллер, у которого будет отдельный View. Контроллеру развесистая иерархия ни к чему.
Кодом людям нужно помогать!
Re[38]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Codealot, Вы писали:
НС>>Это самый натуральный полиморфизм, обеспечивающий полиморфное поведение и скорость равносильную статическим вызовам. C>Это не имеет никакого отношения к виртуальным методам, о которых шла речь. От слова вообще.
Смотри шире. Есть задача полиморфного поведения, когда вызываемый код ведет себя по разному в зависимости от состояния. Виртуальные методы — один из способов это получить. Динамическая кодогенерация — другой.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[33]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Sharov, Вы писали:
S>Ну-ну-ну, я пытался ответить на вопрос, почему в asp .net core (и вообще asp.net), они решили обойтись S>интерфейсом, а не наследованием.
Интерфейс там торже необязателен. И мне не лень, я тебе четвертый раз повторю — ты не прав.
S>В ответ ор, кака-бяка и переход на личности.
Переход на личности был после того как ты три раза пропустил мимо ушей, что ты не прав в своей теории.
S>Т.е. вместо того, чтобы дать ответь
В пятый раз тебе ответь — ты не прав.
S>>>А что плохого? НС>>Лишние ограничения на дизайн, лишняя связность. S>Так может для UI это хорошо?
Это ни для чего не хорошо. Low coupling/high cohesion это самый базовый принцип дизайна софта, все остальное — следствие.
S>>>Зачем сравнивать холодное с мягким -- развесистый UI и контроллер НС>>Затем что они решают похожие задачи. S>Ну не сказал бы -- Forms это больше UI+контроллер (причем, скороее UI)
Ага. И за это их не пнул только ленивый. А потом начали изобретать всякие MVC и MVVM, хотя налазит это все на винформсы, в отличие от aspnet, аки сова на глобус.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[34]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ага. И за это их не пнул только ленивый. А потом начали изобретать всякие MVC и MVVM, хотя налазит это все на винформсы, в отличие от aspnet, аки сова на глобус.
в WPF примерно такое же наследование, как и в формах, а MVVM там родной изначально.
Re[35]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, karbofos42, Вы писали:
НС>>Ага. И за это их не пнул только ленивый. А потом начали изобретать всякие MVC и MVVM, хотя налазит это все на винформсы, в отличие от aspnet, аки сова на глобус. K>в WPF примерно такое же наследование, как и в формах
Такое, да не совсем.
K>а MVVM там родной изначально.
Если бы. Прикручивание туда MVVM вызывает преизрядно проблем с несовместимостью, хотя, конечно, там это сильно проще чем в винформсах. Как раз в силу меньшей связности дизайна WPF.
... << RSDN@Home 1.3.17 alpha 5 rev. 62>>
Re[39]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Смотри шире. Есть задача полиморфного поведения, когда вызываемый код ведет себя по разному в зависимости от состояния. Виртуальные методы — один из способов это получить. Динамическая кодогенерация — другой.
Здесь речь шла о виртуальных методах, от которых предлагалось как-то отказаться. Точка.
Ад пуст, все бесы здесь.
Re[34]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, Ночной Смотрящий, Вы писали:
S>>Ну-ну-ну, я пытался ответить на вопрос, почему в asp .net core (и вообще asp.net), они решили обойтись S>>интерфейсом, а не наследованием. НС>Интерфейс там торже необязателен. И мне не лень, я тебе четвертый раз повторю — ты не прав.
Да пожалуйста, просто никакого обоснования почему не прав не было. Вместо того, чтобы объяснить 2-3 предложения
или кинуть ссылку на обсуждение в SO или msdn, какая-то кака-бяка и хождение по кругу. "Ты не прав потому и потому",
и всех делов. А не "покажи" или "докажи".
S>>В ответ ор, кака-бяка и переход на личности. НС>Переход на личности был после того как ты три раза пропустил мимо ушей, что ты не прав в своей теории.
Я высказал гипотезу, почему было отвергнуто то или иное решение -- в ответ ничего вразумительного.
Я могу заблуждаться, но хотелось бы понять где, а в ответ что-то врод "я -- начальник, ты -- дурак".
S>>Т.е. вместо того, чтобы дать ответь НС>В пятый раз тебе ответь — ты не прав.
См. выше.
S>>Так может для UI это хорошо? НС>Это ни для чего не хорошо. Low coupling/high cohesion это самый базовый принцип дизайна софта, все остальное — следствие.
Конкретно для UI это хорошо. У меня есть базовых грид (Grid) для которого написана куча кода, целый фреймворк+компоненты,
мне надо как-то кастомизировать его поведение (NewGrid), чтобы вместо textbox ячеек где-то показывать checkbox.
Причем NewGrid должен рабоать где и Grid, т.е. как грамотно сказать, NewGrid полиморфен Grid.
Как без наследования максимально эффективно этого добиться?
S>>Ну не сказал бы -- Forms это больше UI+контроллер (причем, скороее UI) НС>Ага. И за это их не пнул только ленивый. А потом начали изобретать всякие MVC и MVVM, хотя налазит это все на винформсы, в отличие от aspnet, аки сова на глобус.
Ага не ага, а сравнения UI и контроллера было некорректным.
Кодом людям нужно помогать!
Re[40]: почему в C# до сих пор нет наследования конструкторов?
Здравствуйте, rameel, Вы писали:
R>С чего бы это будет так работать?! Если дыр нет, то все работает за константное время, и не важно 10 там элементов или 1000
Это свитч то за константное время, когда у него 1000 вариантов?
Ад пуст, все бесы здесь.
Re[42]: почему в C# до сих пор нет наследования конструкторов?
