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

Мне интересно, как поменяются подходы в F#, когда появятся default interfaces.

Мне интересно, как поменяются подходы в F#, когда появятся default interfaces.

а что это?

а что это?

Когда в интерфейсе можно написать реализацию для метода по умолчанию.

Планируется в C#8.

Вместе с изменениями в CLR.

имхо лучше бы они сделали duck typing с неявной реализацие йинтерфейса в случае соответсвия ему сигнатур методов класса, а не занимались изобретением костылей.

имхо лучше бы они сделали duck typing с неявной реализацие йинтерфейса в случае соответсвия ему сигнатур методов класса, а не занимались изобретением костылей.

Насколько я понял, они решили пойти по пути трейтов и, в будущем, тайпклассов.

Насколько я понял, они решили пойти по пути трейтов и, в будущем, тайпклассов.

о, я бы 100 баксов против 10 поставил, что трейтов в стиле scala/rust в С# никогда не будет)) жаль ни кто такие ставки не принимает)))

о, я бы 100 баксов против 10 поставил, что трейтов в стиле scala/rust в С# никогда не будет)) жаль ни кто такие ставки не принимает)))

А интерфейсы с дефолтными методами и свойствами — это еще не трейты?

не думаю. это что-то вроде базового класса, который может участвовать в множественном наследовании, то есть про ООП. трейты - это про ad-hock полиморфизм. Впрочем моё мнение о наследовании ты знаешь - это грех, который надо выжигать калёным железом

а уж множественное...

Понял, спасибо.

> Generic IDisposable http://fssnip.net/7TL

> Generic IDisposable http://fssnip.net/7TL

стесняюсь спросить, а на кой ляд алгебраическим типам IDisposable?

Парни, а как бы вы синглтон/lazy сделали в F#? Допустим у меня есть какая-либо функция сохранения данных в базу, и мне нужно открыть соединение с БД лишь 1 раз перед первым сохранением.

Парни, а как бы вы синглтон/lazy сделали в F#? Допустим у меня есть какая-либо функция сохранения данных в базу, и мне нужно открыть соединение с БД лишь 1 раз перед первым сохранением.

Есть же lazy из коробки let x = lazy (fun _ -> System.DateTime.Now) printf "%O" x.Value

Парни, а как бы вы синглтон/lazy сделали в F#? Допустим у меня есть какая-либо функция сохранения данных в базу, и мне нужно открыть соединение с БД лишь 1 раз перед первым сохранением.

в сферическом вакууме вот так let connectDB = let connection = actualConnect() fun () -> connection в реальной жизни как-то так let connectDB = let mutable connection : Connection = null fun () -> if connection = null then try connection <- actualConnect() Ok connection with e -> Err e.Message else Ok connection

и я бы такую функцию запрятал поглубже в потрохах, поскольку ни о какой ссылочной прозрачности там речи не идёт

Вау. Получается, что connection в замыкании хранится?

Парни, а как бы вы синглтон/lazy сделали в F#? Допустим у меня есть какая-либо функция сохранения данных в базу, и мне нужно открыть соединение с БД лишь 1 раз перед первым сохранением.

Я по другому делал, т.к. IDbConnection является IDisposeable, я делал функцию getConn, которая создавала этот объект и использовал use, типа use conn = getConn

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

У mysql адаптера написано, что он внутри имеет пул соединений, и при вызове Dispose соединение высвобождается, и затем может быть переиспользовано другим DbConnection

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

Эт с каким lazy?

Вот тут написано, что наш эфшарповский lazy — это обычный BCL'ный Lazy<T> с режимом ExecutionAndPublication: http://theburningmonk.com/2013/04/be-lazy-but-be-ware-of-initialization-exception/

То есть конкурентное выполнение будет ок.

То есть конкурентное выполнение будет ок.

Дело не в одновременном получении объекта

Дело в вызове функции запроса, или чтении из ридера

Вызовы не должны пересекаться

Можно пример?

Кажись, он говорит о конкурентном использовании подключения к БД (которое и правда обычно недопустимо).

А разве бд не должна это сама разруливать?

Нет, не должна.

Это локальные дела твоего процесса.

https://habrahabr.ru/post/337880

https://habrahabr.ru/post/337880

Ух! А кто это? Мы знаем автора перевода?

Мне статья понравилась, сразу схватил все с первого раза

Вот бы так же красиво и просто объясняли и другие темы на хабре

Ну так-то это перевод

Да, ничего, что он не описал паттерны фп, а просто описал основы

Да, ничего, что он не описал паттерны фп, а просто описал основы

Мне кажется, что изложения основ всегда и не хватает.

Мне кажется, что изложения основ всегда и не хватает.

согласен, но тогда следовало назать статью "основы"

я ждал описания и сравнения паттернов

я ждал описания и сравнения паттернов

Мне кажется, что все паттерны в ООП — это просто следование некоторым простым принципам при решении задач. Если интересно, в каком виде эти принципы присутствуют в функциональном программировании, то есть неплохая статья. https://github.com/polytypic/blog/blob/master/posts/2014-08-18-solid.md

Вообще, чем паттерны не основы? ?

@gsomix спасибо

Ух! А кто это? Мы знаем автора перевода?

мне больше статья боба мартина понравилась из комментов http://blog.cleancoder.com/uncle-bob/2014/11/24/FPvsOO.html

которая по-сути ответ на нее

Вообще, чем паттерны не основы? ?

Я честно считаю, что принципы ООП, паттерны и SOLID — это основы. Но вот кто-то говорит, что это для миддлов, средний уровень знаний. :)

мне больше статья боба мартина понравилась из комментов http://blog.cleancoder.com/uncle-bob/2014/11/24/FPvsOO.html

Он просто описывает хорошее годное ООП. Такое мы и в F# рады писать. :)

Я честно считаю, что принципы ООП, паттерны и SOLID — это основы. Но вот кто-то говорит, что это для миддлов, средний уровень знаний. :)

А DDD, CQRS+ES - это миддл или сеньор?)

Я честно считаю, что принципы ООП, паттерны и SOLID — это основы. Но вот кто-то говорит, что это для миддлов, средний уровень знаний. :)

иначе "основ" станет так много, что на джуна придётся пол жизни учится

А DDD, CQRS+ES - это миддл или сеньор?)

Не знаю. Если честно, я плохо ориентируюсь в терминах.

Дай бог запомнил, что буковки в SOLID значат.

:D

> Type-Safe effect builder http://fssnip.net/7TM

Eirik Tsarpalis и palladin два моих любимых авторов на fssnip. Всегда что-нибудь хитрое выкладывают. :)

@fvnever ^

Немного оффтопну. MOOC по Haskell. https://www.futurelearn.com/courses/functional-programming-haskell/

А разве бд не должна это сама разруливать?

уважающая себя бд как раз таки умеет это разруливать спокойно (ну кроме монги). а вот драйвер БД - нет. в .net не принято предоставлять конкуретный апи, в лучшем случае напихать костылей с асинхронщиной

Идея для перевода. https://compositional-it.com/blog/2017/09-18-safe-web/index.html

Есть же lazy из коробки let x = lazy (fun _ -> System.DateTime.Now) printf "%O" x.Value

Неправильный пример у вас, Value разное :)

Там надо либо без fun, либо Lazy.Create()

Кажись, он говорит о конкурентном использовании подключения к БД (которое и правда обычно недопустимо).

Да

Но если нет конкурентного, то смысл в lazy?

Тут при любых раскладах не получится применить lazy

Народ, что вы применяете для сериализации/десериализации типов f# в xml (или другие форматы) ? Есть SharpXml, но но мне не понравился. Я не хочу засорять аттрибутами модель. А RegisterSerializer не удобны в использовании. Есть FsPickler - кажется более интересным. Но пока не разобрался. Что используете вы?

используй FsPickler. Всё остальное совсем плохо

Спасибо. Пока не совсем понял как мне кастомизировать сериализацию определенных типов: списков, union type, tupple. Т.е. именно обобщенно, а не для конкретных типов. Нет ли примеров где?

Ещё FsharpLu.

Ещё FsharpLu.

Вроде бы там только json.

Спасибо. Пока не совсем понял как мне кастомизировать сериализацию определенных типов: списков, union type, tupple. Т.е. именно обобщенно, а не для конкретных типов. Нет ли примеров где?

а зачем её надо кастомизировать? Если для внешнего апи, то FsPickler не подойдёт в любом случае

@ruzzke_mir Я хочу определенный формат xml. Т.к. с этим xml могут работать люди и другие программы.

@ruzzke_mir т.е. FsPickler не подойдет для внешних API именно по причине, что в нем нельзя кастомизировать сериализацию для списков, union types, tupples и т.д?

@ruzzke_mir т.е. FsPickler не подойдет для внешних API именно по причине, что в нем нельзя кастомизировать сериализацию для списков, union types, tupples и т.д?

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

@ruzzke_mir Я хочу определенный формат xml. Т.к. с этим xml могут работать люди и другие программы.

тогда используй FsharpLu, а типы изнеачально создавай такие, которые для пользователей

не для каждого типа. а для generic-типов. Т.е. списков, union types, tupples.

FsharpLu он вроде только Json умеет, а Xml нет

не для каждого типа. а для generic-типов. Т.е. списков, union types, tupples.

так не получится в fspickler, и я такого ни где не видел. Если надо особенное представление списка в Xml, то для каждго поля со со списком и DU придётся прописывать схему отдельно. А чем не устраивает дефолтный способ представления списков в XML ?

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

[ Some "" ; None ; Some "message" ] сериализуется в <FsPickler version="4.0.0.0" type="Microsoft.FSharp.Collections.FSharpList`1[Microsoft.FSharp.Core.FSharpOption`1[System.String]]"> <value flags="sequence"> <elem> <Some></Some> </elem> <elem flags="null" /> <elem> <Some>message</Some> </elem> </value> </FsPickler> А я допустим хочу так:

<Document> <Value></Value> <None/> <Value>message</Value> </Document>

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

Тогда напиши свой reflection based сериализатор, это не сложно. Я в своё время так сделал, сейчас использую FSharpLu https://github.com/fpawel/Mil82/blob/master/App/Json/JsonSerialization.fs

Вроде бы там только json.

Да, точно, там только json

Да, точно, там только json

там элементарно дописать для XML

Тогда напиши свой reflection based сериализатор, это не сложно. Я в своё время так сделал, сейчас использую FSharpLu https://github.com/fpawel/Mil82/blob/master/App/Json/JsonSerialization.fs

Попробую покопать в этом направлении. FsPickler написан на основе сниппета Anton Tayanovskyy http://www.fssnip.net/6u Он длинный. Посмотрю его еще.

== А я допустим хочу так: Имхо проще написать тип нужной формы для json/хml, чем мучатся с кастомными правилами сериализации. Конечно если сериализатор нормальный как FSharpLu и у меня по ссылке

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

А... ну или если предлагается сделать тип только для сериализации и конвертор из domain model в этот тип сериализации. Так можно.

А... ну или если предлагается сделать тип только для сериализации и конвертор из domain model в этот тип сериализации. Так можно.

можно ещё проще. сделать конвертор из доменной модели в Dictionary<string,object> и использовать стандартный DataContractSerializer для сериализации в XML. Это самый джедайский метод. При этом никаких типов и кастомных правил придумывать не нужно вообще. В С# ещё проще - всё записать в dynamic, и вася.

Ну на самом деле по количеству кода это почти идентичные методы :)

Спасибо за идею :)

Ну на самом деле по количеству кода это почти идентичные методы :)

интересно было бы сравнить, но думаю для Dictionary<string,object> кода должно получится меньше значительно

минус модель

ммм. да и если конвертер сделать универсальным, то и минус конвертер ))

я уже давно не использую F# и стат. типизацию для всего, что связано с интропом с БД и json, тут dynamic рулит)

\o/ https://twitter.com/sforkmann/status/909815497734213632

Они еще и код отформатировали ?