В этом и кайф, ты не можешь "прост)))" проигнорить кейсы, ты их должен игнорить в явном виде

У тебя общий тип будет - Animal (или как назовешь)

match duValue with | Cat name -> prinfn "Cat with name %s" name | Dog size -> printfn "Dog of size %n" size

https://github.com/mcintyre321/OneOf

Если кличек кошек хочешь из последовательности: animals |> Seq.choose (function Cat name -> Some Name | _ -> None)

https://github.com/mcintyre321/OneOf

Спасибо.

https://github.com/mcintyre321/OneOf

Ну такое.

match duValue with | Cat name -> prinfn "Cat with name %s" name | Dog size -> printfn "Dog of size %n" size

Нет, нет. У меня есть слот, в него кладётся структура, которая будет попадать в ветку DU "слот", нужно match типа структуры сделать, для определения каким конструктором DU воспользоваться. Как раз выражения typeof я не видел (их примеры) для F#, как это сделать?

ну есть хелперы, которые позволяют имя получить

Нет, нет. У меня есть слот, в него кладётся структура, которая будет попадать в ветку DU "слот", нужно match типа структуры сделать, для определения каким конструктором DU воспользоваться. Как раз выражения typeof я не видел (их примеры) для F#, как это сделать?

Через match и :?

Через match и :?

| :? (<help>что тут?</help>) as banana -> Some Slot.Fruit banana

| :? (<help>что тут?</help>) as banana -> Some Slot.Fruit banana

Имя типа.

Имя типа.

| :? (Banana) as banana -> Some Slot.Fruit banana Спасибо за наводку. Сравнение типов на F# быстрое? Каким образом происходит сравнение?

| :? (Banana) as banana -> Some Slot.Fruit banana Спасибо за наводку. Сравнение типов на F# быстрое? Каким образом происходит сравнение?

Такое же как в C#.

Проблема наследования в том, что DU описывает набор всех возможных кейсов, а наследование - позволяет расширять.

Интересную тему подняли полиморфизм vs матчинг) Думаю есть кейсы, когда одно явно лучше, а есть и когда второе

Да, несомненно

Но полиморфизм - это про поведение, а не про данные

ну и матчинг когда от типа зависит разное поведение - это тоже про него

Это сложный вопрос, где должно быть поведение, рядом с данными, или снаружи.

Мне понятнее, когда оно снаружи

Чистые функции, вот это все.

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

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

Construct interface -> find members assignable from

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

Ну дык это не матчингом решается тогда

сделал интерфейс IMessage там поле строковое ActionType, по нему делаю матчинг

Не, так тоже не надо

Лучше на атрибутах, если предполагается множество обработчиков

А не, вру, матчинг сделал по названию топика, на каждый топик свой тип, но в типе поле ActionType и по нему еще один матчинг)

((dynamic)handler).Handle((dynamic)cmd) ?

Лучше на атрибутах, если предполагается множество обработчиков

что именно на атрибутах?

что именно на атрибутах?

По факту матчинг

((dynamic)handler).Handle((dynamic)cmd) ?

да, да) вот такого страха и хотелось избежать))

А меня сейчас форсят именно так писать ж(

А меня сейчас форсят именно так писать ж(

Беги оттуда

так это же Microsoft best practice по написаню микросервисов)

Беги оттуда

Куда?

видели их супер проект с cqrs?

Видели, плакали. Еще тогда, когда CQRS было модно, в 2009м что ли смотрел, или 2010м

да, да) вот такого страха и хотелось избежать))

я вообще не так выезжал в этой ситуации

Короче, главная проблема там, имхо - заматчить тип сообщения на процессор

пиши дайнамик, рантайм разберется!

пиши дайнамик, рантайм разберется!

или ляжет

не ссы, главное!

Ляжет - перезапустим, у нас кубернетес же

(ц) мой куратор

Ладно, пора обедать.

Лучше на атрибутах, если предполагается множество обработчиков

а можно пример? или stop words для гугления

я вообще не так выезжал в этой ситуации

а как?

а как?

https://github.com/Happi-cat/Untech.Practices/blob/develop/Src/Untech.Practices.CQRS/Dispatching/Dispatcher.cs

у меня короче есть ICommand & ICommandHandler<ICommand> и есть CommandHandlerInvoker<TCommand, TCommandHandler> ну а дальше MakeGenericType - cache invoker ну и поиск хэндлера через IoC

если в диспетчере сделать методы женериками, то GetType махнулся бы на typeof НО тут вопрос использования, typeof может факапить если где-то кто-то сможет создать инст ICommand и присвоить не в ConcreteCommand a в BaseCommand и в женерик попадёт не тот T

спасибо) это правда очень похоже на решение с dynamic =) а где код по десериализации сообщений перед диспатчем?

спасибо) это правда очень похоже на решение с dynamic =) а где код по десериализации сообщений перед диспатчем?

ну динамик в моём случае не решил бы вопрос где найти хэндлер (сборка/тип) и пришлось бы MakeGeneric юзать в любом случае, просто что добавивь HandlerInvoker экономлю на кол-ве вызовов makeGeneric а десериализация уже зависит от того где юзать ? в pet-project-е у меня месседж формируется в api исходя из query/body параметров (т.е. route -> concrete command)

у меня просто задача стоит - как десереализовать месседж в concrete command)

ну если они прилетают все на один эндпоинт то либо через Type либо через attribute какой

так а куда аттрибут вешать? надо писать кастомный десериализатор который по одному из филдов месседжа подбирает тип с каким-то навешенным атрибутом?

если аттрибут то да, кастомный десериализатор который будет искать все ICommand с этим аттрибутом и искать тот единсвенный в котором нужное имя/текст/содержимое

Ну вот если мало команд, то тут матчинг гораздо лучше, никаких интерфейсов, рефлексий и неопределенности) Но до каких пор он лучше это вопрос конечно открытый

ну когда мало комманд - да, а что если мы потом захотим объединить модули с разными конекстами в которых независимые комманды в один прожект (т.е. под крышу одного API проекта)

делаем один матчинг сверху который определяет модуль)

в этом кстати преимущество матчинга - можно делать дерево матчингов, а не пытаться определить сразу же

Ого. Потрясно!

Правда?) Я вот наткнулся потом на Rezoom.SQL подумал, что наверное не актуально уже будет https://github.com/rspeele/Rezoom.SQL

только вот это смущает: (query |> QueryAsync <| connection)

Issues всегда открыты для предложений и не только :3

делаем один матчинг сверху который определяет модуль)

а как примерно родительский матчинг будет выглядеть?

одни команды пусть начинаются с Team1. другие с Team2. (типа такого)

Issues всегда открыты для предложений и не только :3

Увы, я очень плохо знаю F#, поэтому даже с трудом понимаю, что именно делает данная строка

Все равно что QueryAsync query connection Я тоже довольно плохо его знаю, как видно наверное :D

наверное был бы смысл сделать сигнатуру QueryAsync connection query, чтобы частично применить соединение и дальше уже закидывать только запросы

одни команды пусть начинаются с Team1. другие с Team2. (типа такого)

ну да, есть смысл, но в этом случает под один DU комманды не объединишь, ведь так?

наверное был бы смысл сделать сигнатуру QueryAsync connection query, чтобы частично применить соединение и дальше уже закидывать только запросы

Согласен, не помню, что меня дернуло сделать так как оно есть сейчас

ну да, есть смысл, но в этом случает под один DU комманды не объединишь, ведь так?

Ну они изначально разделены же. Поэтому наверное смысла под один объединять особо и нет

Правда?) Я вот наткнулся потом на Rezoom.SQL подумал, что наверное не актуально уже будет https://github.com/rspeele/Rezoom.SQL

на магию похоже ?

Что именно ?)

ну подсветка ошибок в sql + выведение типов

по мне так классно, не надо писать все эти модели, как в случае с dapper'ом и нет такой генерации как с EntityFramework'ом. К сожалению не завелось под .net core так, что не пробовал пока

по мне так классно, не надо писать все эти модели, как в случае с dapper'ом и нет такой генерации как с EntityFramework'ом. К сожалению не завелось под .net core так, что не пробовал пока

зато модели можно переиспользовать, например для вставки или апдейта через dapper.contrib

А есть что-то найтивное для Cosmos DB кроме sagan?

по мне так классно, не надо писать все эти модели, как в случае с dapper'ом и нет такой генерации как с EntityFramework'ом. К сожалению не завелось под .net core так, что не пробовал пока

Но свои минусы тоже есть. так что проект fsharp-dapper очень полезный

https://twitter.com/sforkmann/status/973579236928901121

джва года ждал эту фичу)

А почему нужны доп действия для этого?

в целом-то ок, все же

А почему нужны доп действия для этого?

Автоматизация!

https://twitter.com/sforkmann/status/973579236928901121

А если там циклические ссылки?

А если там циклические ссылки?

Должен ошибку кинуть. Я еще не проверял.

Кто-нибудь применял F# в гейм деве?

в любом, мне тут просто пришёл в голову интересный сценнарий, думаю вот совместить приятное с приятным

У нас с @fvnever есть пара идей, но мы нифига не пишем.

Что за идеи? Я имею ввиду, какие технологии можно использовать?

Что за идеи? Я имею ввиду, какие технологии можно использовать?

MonoGame

У нас с @fvnever есть пара идей, но мы нифига не пишем.

Делитесь с сообществом ?

MonoGame

Что на ней можно сделать?

в двух словах?

MonoGame

Забудьте, это старьё. Назовите причину, почему упал на них взор, мб есть альтернатива

Забудьте, это старьё. Назовите причину, почему упал на них взор, мб есть альтернатива

Почему?

Что на ней можно сделать?

Игру. Ну, в смысле, в чем вопрос?

Забудьте, это старьё. Назовите причину, почему упал на них взор, мб есть альтернатива

Unity