Pull to refresh

Comments 7

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

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

В любом случае спасибо, хорошая работа.
Ну а в чем проблема перехватывать исключение и писать его в лог? Вся соль этого подхода проявляется тогда, когда ответственность за правильность выражения перекладывается на пользователя (в нашей старой системе это обеспечивал редактор, который просто не разрешил бы ввести неправильное выражение — типы объектов там были извесны заранее). Динамик позволяет, например, сложить строку и число, так как эта операция переопределена для аргументов такого типа. Или взять разность между двумя датами просто с помощью оператора "-".
Что касается переполнения, да такая проблема может быть, но очень маловероятна — выражения в описаном случае в основном предасталяют собой логические предикаты, количество математики сведено к минимуму.
Я и правда мог бы написать хороший строго типизированый код со всеми проверками, но его размер был бы куда больше тех 500 строк, в которые я вложился здесь, да и времени на него ушло бы неделя :) К примеру, когда мы два года назад писали ту подсистему, она не вошла во второй прототип продукта просто потому, что была еще не готова. Как всегда, динамическая типизация рулит там, где надо быстро и лаконично решить задачу. Если надо надежно и производительно — статика ваш выбор.
>> Или взять разность между двумя датами просто с помощью оператора "-".
Эм. А что, это заслуга dynamic, а не переопределенного оператора "-" в классе даты?

И еще в полушутку — у меня по ощущениям осталось, что динамическая типизация рулит там, где у вас есть время писать unit-тесты :)
Вам не показалось, что в примере слишком много синтаксического шума?
Это означает, что С#, вообще-то говоря, мало подходит для реализации функционала, представляющего AST, например, и другие конструкции, работающие в полях типов: типы объектов, типы типов и так далее.

Еще вопрос — это вы паттерн «интерпретатор» переписали на dynamic, я правильно понимаю? Просто мне кажется, с использованием Reflection или expression trees было бы не намного больше кода.
правильно понимаете, но рефлексия была бы жутко нечитабельной. вообще говоря, да, на каком-нибуть ФП все было бы намного компактнее.
Все это мне напомнило Workflow Foundation, где предикаты которые вы пишете якобы на C# на самом деле сериализуются в монтрообразный, огромный кусок абсолютно нечитабельного XML. В принципе понятно, что вы здесь пытаетесь делать, только вот я не очень насчет XML в целом. Хотя если у вас заказчик блоки на диаграмме перетаскивает, возможно именно XML и имеет смысл использовать. По крайней мере в DSL Tools, например, все сериализуется именно в XML.
Sign up to leave a comment.

Articles