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

V>Потому что мои Op выполняются, считай, сразу, без стадии компиляции в CIL на моей стороне.
Ну, ок. Статика. Если удастся сконструировать их статически.

S>>Вызываем на нём Compile(), и получаем полноценный бинарный код, ничуть не хуже, чем у AddIntOp.Execute().

V>Берём серверную сторону, сервак работает 24x7.
V>Серверная сторона не для красного словца — та задача изначально под серверную сторону потребовалась.
V>Compile каждый раз порождает новый код, который остаётся в памяти процесса и нет способа этот мусор собрать.
А зачем делать это каждый раз, когда можно один раз проинициализировать статическое поле результатом Compile, а потом обращаться к нему за стоимость вызова IOperation<int>.Execute или даже быстрее?
V>Перезагрузки доменов теперь тоже нет.
Почему не скомпилировать это в DynamicMethod, который прекрасно соберётся безо всякой выгрузки доменов?

V>Через тип-словарик это можно было делать и раньше, но конкретно в этой задаче генерик-реализация экономила мало, бо в том "калькуляторе" использовалось два числовых типа всего — целочисленный long и double. Int — это я просто суть происходящего показывал на пальцах. И обслуживать те типы "раздельно" тоже было удобно, бо напрямую long и double не взаимодействуют в арифметических операциях, а только через предварительную промежуточную операцию приведения long к double, т.е. простой if в коде парсера-билдера оперирует не-генерик типами, а обычными, что тоже где-то удобно, в отсутствии протягиваемого для type-билдера лишней пары генерик-параметров (T и TOpProvider where TOpProvider : IOpProvider<T>).
Эмм, если где-то есть парсер-билдер, то никакой статики уже не будет.

V>Замечаний два, они взаимосвязаны:
V>- Expression вшит в C# и нет возможности подставить некий свой expression builder для ламбд;
Кстати, где-то пробегал FR по внедрению расширяемого expression builder.
V>- сам ExpressionBuilder обслуживает не все виды лямбд, хотя именно для их обслуживания создавался.


V>https://docs.microsoft.com/ru-ru/dotnet/csharp/whats-new/csharp-8
Нет, "списочек" — вот: https://github.com/bartdesmet/ExpressionFutures/blob/master/CSharpExpressions/README.md

V>Не, важно понимать, что вопросы планирования, раздачи приоритетов, оценки трудоёмкости тех или иных вещей — это одна из важнйших стадий в любой инженерной разработке.
А то.

V>Например, гугл строго няньчится со своим Хромом, хотя проект и в опен-сорсе.
Да, есть ещё несколько признаков того, что "няньки нет". Но это будет работать до тех пор, пока это отсутствие няньки не будет приводить к реальному геморрою реальных пользователей языка.

V>В реальных коммерческих проектах всегда весы — трудоёмкость vs получаемые плюшки.
Точно. Именно это я и написал.

V>А здесь ситуация вдвойне забавной получилась, бо поддержка статических локальных методов в expression builder не стоит дороже написания нового кода, который сгенерирует и выдаст новую ошибку компиляции с новым номером при попытке использовать статические локальные методы в expressions.
Возможно. Я в код компилятора не смотрел, не могу сказать, что было дороже.

V>Рассуждая похожим образом:
V>- отсутствие linq в дотнете аффектило примерно 0 человек в мире
V>- отсутствие дотнета аффектило примерно 0 человек в мире
Вот эти натянутые аналогии показывают, что вам пока рано в продакт менеджмент
Отсутствие linq в дотнете аффектило миллионы человек в мире. Хейльсберг в своё время очень убедительно обосновывал, почему был разработан Linq — а ведь это потребовало огромных инвестиций. Уж очень дофига принципиально нового было добавлено в язык.
Отсутствие дотнета аффектило, в первую очередь, позиции Microsoft, которому хотелось делать свою JVM, но Sun не давала им пилить JVM в нужную микрософту сторону.
V>Посмотри в зеркало, плиз, на каждый именно твой пост запросто можно отвечать "это никому не нужно" и "ты всё-равно до этого не доживёшь", бо ты пишешь сюда именно такой материал, заведомо допускающий именно таких оценок.
Ну естественно. По умолчанию, linq2d нафиг никому не упал. Если бы я пробовал продать его идею потенциальному инвестору, то всё закончилось бы ещё до начала.
V>А зачем это делать ручками, если комплятор и так переносит статик локал в простой приватный статик? (в отличие от нестатик локал)
V>Т.е. суть именно в этом — фича уже готова и работает, ничего даже делать не надо.
Так это же везде так — ну возьми, замени (4, 5) на ValueTuple.Create(4, 5) — всё ж готово. Но нет, не делают.

V>Вряд ли дотнетные разработчики действительно сошли с ума, скорее, они рассматривают дотнетное сообщество как сборище инфантильных детей.
V>Им заранее облом отвечать на вопросы из разряда "а почему статические локальные ф-ии в linq использовать можно, а нестатические нет?".
V>Вот и весь секрет.
Вот если честно, меня вопросы внутренних процессов принятия решений не очень интересуют. Мне и так приходится ежедневно принимать рещения, которые снаружи могут выглядеть совершенно нелогичными.

V>Что лишний раз напоминает о том, что ты плохо разбираешься в мотивации других людей.
Почему вы решили, что вы разбираетесь лучше? Мы гадаем на кофейной гуще. У меня версия — feature didn't jump over the bar. Ваша идея — "лень было объяснять разницу между статик локалами и нестатик локалами".
Хотя технически я не вижу разницы между статик и нестатик локалами — всё равно строится замыкание. Если уж делать — то можно поддерживать обоих.
V>Отчасти это объясняет странные пробуксовки в обсуждении с тобой на ровном месте.


V>Разве?
V>Тебе можно вернуть твои же возражения — решается так-то и так-то.
V>

V>Func<(int, int)> f = ()=>(42, 42);

V>Expression<Func<(int, int)>> f1 = ()=> ValueTuple.Create(42, 42);
V>

V>Решения принимаются в несколько этапов, происходящих итеративно: из формулирования целей и приоритетов, затем из анализа потенциальной трудоёмкости задач, соотнесения с располагаемыми ресурсами, goto на начало.
Именно. И вот этот процесс привёл к тем результатам, которые мы и наблюдаем.