Рекомендации спроектировать # библиотеку C вполне можно использовать с F #

Question

Я просто хочу сказать, что это вопрос не противоположна

Best approach for designing F# libraries for use from both F# and C#

Здесь я не спрашиваю, как проектировать функциональные библиотеки письменного C#, который будет использоваться в обоих мирах.

Я хотел бы знать хорошие практики на обнимала дизайн выбор или избежать, чтобы получить разумный компромисс делают эту библиотеку полезной из F #.

практики, как (например):

• Предохранять иерархии объектов как можно более простым

• избегают мутирует состояние объектов, но возвращать новые

• и т.д ...

Любой, кто уже это сделал, может делиться им опыт?

Примечание стороны

Это Интересно отметить этот проект ОСС, IronJS. Да, это написано в F #, но автор разоблачает два специализированных хоста IronJS.Hosting.FSharp и IronJS.Hosting.CSharp.

Answer 1

Представьте, что в один прекрасный день вы хотели бы переписать свою библиотеку C# в F # для лучшего удобства использования. Вот пути вы, вероятно, принять:

Я сосредотачиваюсь на пути "Императив C# -> Функциональные C# -> Функциональные F # -> Идиоматические F #". Чем более функциональна ваша библиотека C#, тем более удобна ваша библиотека в F #. Функциональный стиль помогает повысить композитоспособность и ближе к идиоматическому коду F #. Вдоль этих линий, вы можете:

• Объятия неизменность по умолчанию принципе. Если вы не знаете, нужно ли обновлять поле/свойство позже, сначала отметьте его readonly.
• Следуйте на основе выражения и декларативного стиля программирования. Операции LINQ - хорошие примеры.
• Используйте неизменяемые коллекции или изменяемые коллекции неизменным образом. С introduction of C# immutable collections он должен быть проще, чем когда-либо прежде.

Фотография взята с F# for fun and profit 's Porting from C# to F# series. Они очень полезны; зная, как концепции C# выражаются в F #, улучшат удобство использования вашей библиотеки.

Трудно избежать объектно-ориентированных функций C#. Помните, что вывод типа F # не очень хорошо работает с этими функциями. Вдоль линии поддержания иерархии объектов просто, вы должны уменьшить количество перегрузок элементов. Большое количество перегрузок элементов легко смущает проверку типа F #. Кроме того, это не помешает распределить тонкую обертку F # с вашей библиотекой C#. Некоторые вещи, которые вам нужно сделать, это превратить некоторые методы в функции модуля и создать Active Patterns для разложения иерархии объектов.

Answer 2

Взаимодействие с существующими библиотеками .NET было главной целью проекта F #, поэтому для библиотек не требуется никаких ограничений.

Это говорит о том, что из-за более строгой типизации F # есть несколько шаблонов, которые приводят к слегка clunkier-коду. Шаблон строителя - один.

var bldr = new StringBuilder(); 
bldr.Append("abc"); //ignoring return value 

против

bldr.Append("abc") |> ignore //must be explicitly ignored 

Но это легко обойти с помощью метода расширения или пусть переплет функции. Итог: interop - одна из сильных сторон F # и наибольших достижений.