В общем, elmish.wpf пока отправляется на свалочку, походу

ПОтому как слабо применима в реальных сценариях

Как это ни прискорбно

ну как я понял это пока всего лишь прототип

Да там все прототипы

ПОходу

Лан, буду свой писать

С акторами

ну оригинальный Elmish вполне себе production ready, а вот возня Сайма с Xamarin и WPF - прототипы

Ну в оригинальном elmish нет проблемы шаблонов

Там, как я понимаю, на выходе html

да, все так

Тут ситуация посложнее

поэтому я и не особо верю в идею TEA для Xamarin или WPF

И к ней не имеет смысла подходить с позиций веба

ну в случае с легаси XAML-based фреймворков - да

Вот надо тебе десктоп написать

Что выберешь?

а вот тот же Flutter от гугла показал, что React-way вполне пригоден для мобильников

Что выберешь?

Electron

не кидайте сильно какашками ))

КОторый жрет дожопы?

Мне все же надо, чтобы надежно работало

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

Мне все же надо, чтобы надежно работало

Надежно и под винду - WPF

Надежно и под винду - WPF

ВОт и я о том

Ща покумекаю, как актор модель без напряга встроить, и все будет ок

Скорее всего модель и будет актором

Я было эксперементировал с Akka.net + UWP . Норм, работало :)

Какой подход использовал?

Как в модели данные передавал?

О какой модели речь?

ViewModel

создавал actor который связывал модель с представлением

он держит ссылку на VM и при получении каких-либо сообщений мутировал ее

А, ну я похожий использую

да, в принципе простой и рабочий вариант

https://twitter.com/migueldeicaza/status/1018632568374218752?s=19

Я не оч понял

Рашен хакерс

блин, может знает кто: При публикации БД dacpac (mssql) надо чтоб удалились вьюхи. 4шт. Но сколько раз я генерирую скрипт, там нет кода для удаления вьюх. И вьхи удалены из схемы ssdt

Там можно рукопашные скрипты писать, это раз

Во-вторых , если в актуальной базе не было вьюх, то и код сгенерен не будет

Там можно рукопашные скрипты писать, это раз

точно, забыл про Pre Script,

Еще и Post есть вроде

Но все это хорошо работает, когда в базе хранится версия

Во-вторых , если в актуальной базе не было вьюх, то и код сгенерен не будет

да в этом и прикол. Вьюхи были удалены из Source, но они в упор не удаляются из target БД.

Еще и Post есть вроде

есть есть.

Я с этим лет 5 назад плотно баловался

Но все это хорошо работает, когда в базе хранится версия

версия? типо обновлять или не обновлять записи в бд? кстати, а хорошая мысль. Мы просто через проверку делаем IF EXSITS

Заводится табличка с версией бд

И кастомные скрипты опираются на нее

Запускаться им или нет

Это довольно много проблем убирает

ааа неее. Я думал через байт массив. Типо вставились данные версия +1

хотя с чем сравнивать тогда. Короче спасибо)

ПЖлст

Привет, помогите придумать ФП решение для следующей задачи. На входе есть JSON с коллекцией элементов, разного типа. На выходе надо получить коллекцию строк. При решение этой задачи встает две подзадачи: 1) Как в "типах" (десериализовано) должна выглядить эта JSON-коллекция разных объектов? 2) Как трансформировать эту коллекцию в коллекцию строк? И самое сложное, как это сделать с учетом expression-problem (те добавлять новые типы и трансформации, не меняя старый код)?

Так судя по докам https://wiki.haskell.org/Heterogenous_collections#Existential_types Мне нужны: - HList - Existential types Но это уже какой-то OOHaskell 👽

Так судя по докам https://wiki.haskell.org/Heterogenous_collections#Existential_types Мне нужны: - HList - Existential types Но это уже какой-то OOHaskell 👽

type Showable = abstract member Show: unit -> unit type Showable<'a>(item: 'a) = interface Showable with member __.Show() = item.ToString() |> printfn "%s" let pack anything = Showable anything :> Showable let hlist = [ pack "1" pack 1 pack (Some 1.)] hlist |> List.iter (fun x -> x.Show()).

генерик интерфейс чтобы избежать боксинга, т.к. он всё к obj сведёт

type Showable = abstract member Show: unit -> unit type Showable<'a>(item: 'a) = interface Showable with member __.Show() = item.ToString() |> printfn "%s" let pack anything = Showable anything :> Showable let hlist = [ pack "1" pack 1 pack (Some 1.)] hlist |> List.iter (fun x -> x.Show()).

А если мне нужные разные реализации Show для разных типов?

ну началось

:D

Так для этого все и задумывалось, зачем мне обертки что бы в итоге дергать toString() 🤷‍♀️

ну так сейчас и получается что show для каждого типа по-своему реализуется

ToString() дёргается от дженерика 'a

ты там можешь чо хочешь написать

хоть ad-hoc полиморфизм, что как бы полиморфизм, но почему-то презираемый. Математически он полиморфизм поэтому любители чистоты просто мозги ебут

вот тебе разная реализация через ад-хок :D Но т.к. боксинга не избежать, то удалим ненужный генерик интерфейс и бесполезный pack let polyShow x = x |> box |> function | :? string as s -> sprintf "Это строка %s" s | :? int as u -> sprintf "Это число %d" u | :? Guid as g -> sprintf "Это гуид %O" g | x -> sprintf "Это какое-то говно %A" x type Showable(any: obj) = abstract member Show: unit -> unit default __.Show() = polyShow any |> printfn "%s" let hlist = [ Showable "1" Showable 1 Showable (Some 1.)] hlist |> List.iter (fun x -> x.Show())

заметим что функция polyShow уаще нормально отинферилась как 'a -> string

Акки обписался,походу :)

:D

Боксинг же фуфуфу

Я просто люблю рабочие решения

согласен, поэтому вариант выше лучше

Там проще можно

через генерик без боксинга

Хотя не

Через op_explicit не получится

к сожалению F# чот не умеет матчить типы без боксинга. Я его понимаю чутка, но не понимаю