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

V>>Облом было ради такой задачи возиться аж с опкодами.
S>С какими ещё опкодами?
S>Во-первых, там внутри — dynamicMethod. https://stackoverflow.com/questions/43041190/do-compiled-expression-trees-leak
S>Во-вторых, даже если бы его там не было, то достаточно самому состряпать DynamicMethod и отдать его в Expression.CompileToMethod().

Если я сказал, что с выходом Expression посмотрел на возможность построения альтернативных Expression (т.е. неких своих), то как на момент их разработки я мог взять Expression и DynamicMethod?

И какие плюшки, кроме ощущения причастности к новизне, должно было дать переписывание готового кода на более тяжеловесную технологию?


V>>Как можно желать того, о чём не в курсе? ))
S>Аффект — это от английского affect = "to act on, to change something".

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

А в случае отсутствия поддержки статических локальных методов — догадываюсь, меня это касается. ))


S>Речь не о том, что кто-то из пользователей чего-то хотел. А о том, что миллионы людей страдали, описывая SQL в строковых константах.

Ну, у нас когда-то был свой query builder, недалеко от методов-расширений Linq уехало.
Но без поддержки query-синтаксиса.

В любом случае, даже с появлением linq запросы на обновление и удаление точно так же требовали генерирования SQL каким-либо образом вне Linq.
Т.е., из CRUD linq повлиял только на одну букву.

(и да, я в курсе про остроумное решение с синтаксисом обновления в ORM-библиотеке за авторством IT)


S>Нуу... да. Теоретически можно замутить свой SinglecastDelegate на основе managed function pointer, а в компилятор запилить умение компилировать лямбду в него .

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

Делегаты в этом смысле обеспечивают абстракцию.
Делегат хранит адрес целевой ф-ии и знает как надо вызывать эту ф-ию — подставляя значение сохранённого object в кач-ве this или нет.
Это разные вызовы с разной арностью при одинаковой внешней арности делегата.


S>Тогда лёгким манием руки дропаем нынешний код Func<...>, переименовываем SinglecastDelegate<...> в Func<...>, и наслаждаемся.
S>Мультикастами могут быть только Action<...>.

Разве?
Что выведет:

Func<int> f1 = () => 42;
Func<int> f2 = () => 43;
Func<int> f3 = (Func<int>)Delegate.Combine(f1, f2);
WriteLine(f3());

?


V>>Если некая контора отпустила некий стандарт в свободное плавание, то за каким чёртом у неё остаётся возможность контроллировать дальнейшее развитие этого стандарта?
V>>Сюрр...
S>Свободное плавание явы началось только в ноябре 2006.

В смысле, заопенсорсили реализацию?
Я про стандарт языка говорил.
Java Community Process был создан в 90-е, стандарт на язык был опубликован тогда же.

Но нельзя присвоить опубликованный стандарт языка, если нет патента.
А патент на язык не дадут.

Любой может пользоваться стандартом, форкать в своих интересах на своё усмотрение и т.д.
Это личное дело субъекта предпринимательства.

Т.е., юридической основы для иска не было.


V>>Я же отслеживаю фичи, обсуждения, расставляемые приоритеты и как вообще принимается решения о назначении приоритетов.
V>>Сейчас фичи включаются в релизы по мере фактической готовности, а приоритеты расставляются исходя из того, есть кому заниматься такой-то задачей или нет.
S>Это вы сейчас про свою секретную компанию, или про дотнет?

Про дотнет.
В нашей компании всё стандартно — ресурсы перекидываются по велению руководства.


S>Если про дотнет, то мы оба неправы.
S>Исходно локальные функции прекрасно работали в Expression Trees, и там захватывался ровно mangled method name — всё, как вы хотели.
S>Вот pull request, который это изменил: https://github.com/dotnet/roslyn/pull/3849
S>Не было никаких комитетов и обсуждения "добавить их в expression builder или нет", не было оценок стоимости, полезности, и движения в бэклоге.
S>Не было никаких "нам сложно объяснять, почему статик можно, а нестатик нельзя" — было можно оба.

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

        var expressions = new List<Expression<Func<int>>>();

        for(var i = 0; i < 4; i++)
            expressions.Add(() => i);

        expressions.ForEach(e => Console.WriteLine(e.Compile()()));

Выведет

4
4
4
4

О захвате мутабельной переменной i компилятор честно выдаст warning при компиляции.
Но локальная ф-ия может скрыть свою мутабельную природу.
А как обеспечить чистоту функций на уровне языка — непонятно.


S>Просто конкретная Эшли Хаук решила, что "References to local functions are now disallowed in expression trees, which may or may not change in the future (Previously they were generated as a reference to a mangled method name, which seemed wrong)".
S>Почему wrong? Да потому, что "local functions in general are bad" (смотреть обсуждение PR). Всё. Это reason enough.

Про локальные я полностью согласен — это непредсказуемая дичь в случае Expression и обычных делегатов, т.к. не всегда очевидно, что именно захватывается и где, т.к. таких локальных ф-ий может быть несколько, но они шарят общий контекст.

Но статические локальные ф-ии чисты относительно контекста, т.е. не подменяют значений и ссылок локальных переменных.


V>>А в эту область (exression и прочий сахар) разработки нужны люди навроде тебя, любящие дотнет в его исходной парадигме, чтобы холили и лелеяли такой взгляд на вещи в платформе, усиливали своим вкладом те самые моменты.
V>>Но сейчас там задают тон люди, не принявшие исходную парадигму, т.е. твои "природные дотнетные враги", навроде меня. ))
S>И это тоже выглядит неверным. Я вот пока не понимаю, почему де Смет не делает Pull Request. Уже больше года, как поддержка всего на свете в Expression готова.

Может, понимает, что не пройдёт.
Или видит недостаточный приоритет этой задаче.

Разобрать серьезный PR — это лужу перешагнуть.
У нас на работе как начинаю разбирать... Иногда ловишь себя на мысли, что быстрее было самому сделать чем тщательно объяснять десяток одновременно участвующих тонкостей.
А в его коде этих тонкостей сотни.
Это нужна приличная команда для верификации такого PR, которая будет много дней разбирать его код.

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

V>>Облом было ради такой задачи возиться аж с опкодами.
S>С какими ещё опкодами?
S>Во-первых, там внутри — dynamicMethod. https://stackoverflow.com/questions/43041190/do-compiled-expression-trees-leak
S>Во-вторых, даже если бы его там не было, то достаточно самому состряпать DynamicMethod и отдать его в Expression.CompileToMethod().

Если я сказал, что с выходом Expression посмотрел на возможность построения альтернативных Expression (т.е. неких своих), то как на момент их разработки я мог взять Expression и DynamicMethod?

И какие плюшки, кроме ощущения причастности к новизне, должно было дать переписывание готового кода на более тяжеловесную технологию?


V>>Как можно желать того, о чём не в курсе? ))
S>Аффект — это от английского affect = "to act on, to change something".

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

А в случае отсутствия поддержки статических локальных методов — догадываюсь, меня это касается. ))


S>Речь не о том, что кто-то из пользователей чего-то хотел. А о том, что миллионы людей страдали, описывая SQL в строковых константах.

Ну, у нас когда-то был свой query builder, недалеко от методов-расширений Linq уехало.
Но без поддержки query-синтаксиса.

В любом случае, даже с появлением linq запросы на обновление и удаление точно так же требовали генерирования SQL каким-либо образом вне Linq.
Т.е., из CRUD linq повлиял только на одну букву.

(и да, я в курсе про остроумное решение с синтаксисом обновления в ORM-библиотеке за авторством IT)


S>Нуу... да. Теоретически можно замутить свой SinglecastDelegate на основе managed function pointer, а в компилятор запилить умение компилировать лямбду в него .

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

Делегаты в этом смысле обеспечивают абстракцию.
Делегат хранит адрес целевой ф-ии и знает как надо вызывать эту ф-ию — подставляя значение сохранённого object в кач-ве this или нет.
Это разные вызовы с разной арностью при одинаковой внешней арности делегата.


S>Тогда лёгким манием руки дропаем нынешний код Func<...>, переименовываем SinglecastDelegate<...> в Func<...>, и наслаждаемся.
S>Мультикастами могут быть только Action<...>.

Разве?
Что выведет:

Func<int> f1 = () => 42;
Func<int> f2 = () => 43;
Func<int> f3 = (Func<int>)Delegate.Combine(f1, f2);
WriteLine(f3());

?


V>>Если некая контора отпустила некий стандарт в свободное плавание, то за каким чёртом у неё остаётся возможность контроллировать дальнейшее развитие этого стандарта?
V>>Сюрр...
S>Свободное плавание явы началось только в ноябре 2006.

В смысле, заопенсорсили реализацию?
Я про стандарт языка говорил.
Java Community Process был создан в 90-е, стандарт на язык был опубликован тогда же.

Но нельзя присвоить опубликованный стандарт языка, если нет патента.
А патент на язык не дадут.

Любой может пользоваться стандартом, форкать в своих интересах на своё усмотрение и т.д.
Это личное дело субъекта предпринимательства.

Т.е., юридической основы для иска не было.


V>>Я же отслеживаю фичи, обсуждения, расставляемые приоритеты и как вообще принимается решения о назначении приоритетов.
V>>Сейчас фичи включаются в релизы по мере фактической готовности, а приоритеты расставляются исходя из того, есть кому заниматься такой-то задачей или нет.
S>Это вы сейчас про свою секретную компанию, или про дотнет?

Про дотнет.
В нашей компании всё стандартно — ресурсы перекидываются по велению руководства.


S>Если про дотнет, то мы оба неправы.
S>Исходно локальные функции прекрасно работали в Expression Trees, и там захватывался ровно mangled method name — всё, как вы хотели.
S>Вот pull request, который это изменил: https://github.com/dotnet/roslyn/pull/3849
S>Не было никаких комитетов и обсуждения "добавить их в expression builder или нет", не было оценок стоимости, полезности, и движения в бэклоге.
S>Не было никаких "нам сложно объяснять, почему статик можно, а нестатик нельзя" — было можно оба.

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

        var expressions = new List<Expression<Func<int>>>();

        for(var i = 0; i < 4; i++)
            expressions.Add(() => i);

        expressions.ForEach(e => Console.WriteLine(e.Compile()()));

Выведет

4
4
4
4

О захвате мутабельной переменной i компилятор честно выдаст warning при компиляции.
Но локальная ф-ия может скрыть свою мутабельную природу.
А как обеспечить чистоту функций на уровне языка — непонятно.


S>Просто конкретная Эшли Хаук решила, что "References to local functions are now disallowed in expression trees, which may or may not change in the future (Previously they were generated as a reference to a mangled method name, which seemed wrong)".
S>Почему wrong? Да потому, что "local functions in general are bad" (смотреть обсуждение PR). Всё. Это reason enough.

Про локальные я полностью согласен — это непредсказуемая дичь в случае Expression и обычных делегатов, т.к. не всегда очевидно, что именно захватывается и где, т.к. таких локальных ф-ий может быть несколько, но они шарят общий контекст.

Но статические локальные ф-ии чисты относительно контекста, т.е. не подменяют значений и ссылок локальных переменных.


V>>А в эту область (exression и прочий сахар) разработки нужны люди навроде тебя, любящие дотнет в его исходной парадигме, чтобы холили и лелеяли такой взгляд на вещи в платформе, усиливали своим вкладом те самые моменты.
V>>Но сейчас там задают тон люди, не принявшие исходную парадигму, т.е. твои "природные дотнетные враги", навроде меня. ))
S>И это тоже выглядит неверным. Я вот пока не понимаю, почему де Смет не делает Pull Request. Уже больше года, как поддержка всего на свете в Expression готова.

Может, понимает, что не пройдёт.
Или видит недостаточный приоритет этой задаче.

Разобрать серьезный PR — это не лужу перешагнуть.
У нас на работе как начинаю разбирать... Иногда ловишь себя на мысли, что быстрее было самому сделать чем тщательно объяснять десяток одновременно участвующих тонкостей.
А в его коде этих тонкостей сотни.
Это нужна приличная команда для верификации такого PR, которая будет много дней разбирать его код.