什么是缺乏OO或命令式F＃？

问题描述

很多时候，我听到F＃不适合特定的任务，如UI。 使用正确的工具，是一种常见的短语。

除了缺少的工具，比如一个WinForms / WPF / ORM设计，我不知道究竟是缺少F＃ - 诚实！然而，特别是UI，我听说C＃只是它更好。所以，势在必行使用时什么是F＃中的实际差异和遗漏？

下面是我想出了一个清单：

• 很多缺少工具支持




• F＃仍然是测试版




• 您的开发人员不知道F＃

  
  
  
  
  
  • 我想不考虑这些点，因为他们是不是真的固有的F＃
  
  



• Mutables需要可变或需要是裁判，裁判的需求！取消引用




• Mutables分配以< - 与ref使用：=（他们都是1个字不仅仅是=）




• VAL需要DefaultValueAttribute得到一个默认值




• F＃不排放隐含接口




• 受保护的成员更难以对付




• 没有自动属性

$抽象b类$ b

• 实施虚拟成员需要两个定义




• 报价对LINQ的表达树产生的树木比略有不同C＃/ VB（恼人的期望在一个特定的格式及其表达的API）




• 没有stackalloc




• F＃不具备的：条件运算符




• 指针可能会被视为在F＃更麻烦




• 代表/事件有可能会被认为是比较烦琐（我认为它们更容易，但至少它们是不同的）




• 没有自动类型转换（如int浮动，或隐式转换）




• 可能为空（C＃的无特殊语法的支持？键入注释和？ 。运营商，以及使用运营商的nullables）




• 没有自动向上转型为公共基类或拳击（例如：设x：OBJ =如果为真，那么1还有喜//这将不会进行类型检查）




• 值不能没有警告（忽略绕过它）




• 没有C风格的语法：）

要的问题是：哪些是阻碍写当务之急还是面向对象的代码？为什么？（短的例子）？哪些我错过了？什么是最好的解决方法，他们为什么还不够？

的请注意：的，我说的不是写所谓地道F＃和我当然不是在谈论函数式编程。我沿着如果我强迫自己写的F＃界面或命令/面向对象的代码，使用F＃OO /势在必行的功能和一流的类型，有什么伤害最深的？

$ B $线条更感兴趣b

奖金
。如果你不知道F＃，但使用C＃或VB.NET和认为这是某些情况下一个更好的工具，请注明具体的语言功能和语法你发现有吸引力的。

解决方案

至于OO的东西，我的名单可能是

• 您提到的关于可烦恼和障碍接口和虚函数一些事情;没有你提到的自动道具也是一种耻辱


• OO框架有时需要很多相互递归类，F＃目前迫使你把一个文件（在类型......和......然后......块）


• 如果您需要调用在派生类中两个不同的基础构造，您必须使用明确的类语法（如提到的这里）

这表示，F＃已经于二OO部门的优势太像类型推断，当地的功能，简洁的语法，...所以总体来说，我可以称之为一洗在重OO'的部门。

（我已经做几乎任何种类的UI编程，所以我没有资格来衡量在那里。）

（编辑：我也想插嘴说，即使你明确选择与问题排除'工具'，我认为重要的工具了一下，在这方面的其他托管VS语言EXCEL）

Many times I hear that F# is not suited to particular tasks, such as UI. "Use the right tool" is a common phrase.

Apart from missing tools such as a WinForms/WPF/ORM designer, I'm not sure what exactly is missing in F# -- honestly! Yet, particularly with UI, I'm told that C# just does it better. So, what are the actual differences and omissions in F# when using it imperatively?

Here is a list I came up with:

• Lots of missing tool support

• F# is still beta

• Your developers don't know F#

  • I'd like to not consider those points, as they aren't really intrinsic to F#

• Mutables need "mutable" or need to be ref, ref needs ! to dereference

• Mutables assign with <- and ref uses := ( they're both 1 more character than just = )

• val needs DefaultValueAttribute to get a default value

• F# doesn't emit implicit interfaces

• Protected members are more difficult to deal with

• No automatic properties

• Implemented virtual members on abstract classes require two definitions

• Quotations-to-LINQ-Expression-Trees produces trees slightly different than C#/VB (annoying for APIs that expect their Expressions in a specific format)

• No stackalloc

• F# doesn't have the ?: conditional operator

• Pointers might be considered more cumbersome in F#

• Delegates/events might possibly be considered more cumbersome (I'd argue they're easier, but at a minimum they're different)

• No automatic type conversions (like int to float, or implicit casts)

• No special syntax support for Nullable (C#'s ? type annotation and ?? operator, as well as using operators on nullables.)

• No automatic upcasting to common base class or boxing (ex: let x : obj = if true then 1 else "hi" // this won't typecheck)

• Values can't be discarded without a warning ("ignore" to get around it)

• Doesn't have C-style syntax :)

To the question: Which of these are a hindrance to writing imperative or OO code? Why (short examples)? Which ones did I miss? What are the best workarounds, and why are they not enough?

Please note, I'm not talking about writing so-called idiomatic F#, and I'm certainly not talking about functional programming. I'm more interested along the lines of "If I were to force myself to write UI or imperative/OO code in F#, using F# OO/imperative features and class types, what hurts the most?"

BonusIf you don't know F# but use C# or VB.NET and think it's a better tool for some situations, please indicate the specific language features and syntax you find appealing.

解决方案

With regards to OO stuff, my list might be

• You mentioned some things about interfaces and virtuals that can be annoyances or hindrances; lack of auto-props you mentioned is also a shame
• OO frameworks sometimes require many mutually recursive classes, which F# currently forces you to put in one file (in a 'type ... and ... and ...' block)
• If you need to call two different base constructors in a derived class, you have to use the 'explicit' class syntax (as mentioned here)

That said, F# has strengths in the OO department too, like type inference, local functions, succinct syntax, ... so overall I might call it a wash in the 'heavily OO' department.

(I have done almost no UI programming of any kind, so am not qualified to weigh in there.)

(EDIT: I also want to interject that, even though you're explicitly choosing to exclude 'tooling' from the question, I think tooling matters a bit, and in this respect the other managed VS languages excel.)

这篇关于什么是缺乏OO或命令式F＃？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！