很酷的新 F# 3.0 功能类型提供程序可用于弥合 F# 数据类型或类与 XML 或 WSDL 等数据源结构之间的不匹配。然而,这种不匹配在其他 .NET 语言(如 C#)中也是一个挑战。
我想在 C# 代码中使用 F# 3.0 提供程序。如果有的话,我该怎么做?此外,如果我们不能,C# 实现需要什么才能使用它们?
很酷的新 F# 3.0 功能类型提供程序可用于弥合 F# 数据类型或类与 XML 或 WSDL 等数据源结构之间的不匹配。然而,这种不匹配在其他 .NET 语言(如 C#)中也是一个挑战。
我想在 C# 代码中使用 F# 3.0 提供程序。如果有的话,我该怎么做?此外,如果我们不能,C# 实现需要什么才能使用它们?
我认为@kvb 很好地概述了一些技术难题。我同意类型推断是有问题的——你基本上只能在本地使用提供者生成的类型,类似于匿名类型。我认为 C# 可能会在 Roslyn 中提供类似的东西,但我怀疑它是否会像在 F# 中一样优雅流畅地集成(其中类型提供程序实际上是语言功能,而不仅仅是工具)。
要回答您的两个具体问题:
[如何] 在 C# 代码中使用 F# 3.0 提供程序?
F# 类型提供程序实际上只有 F# 编译器才能理解,因此您需要在 F# 中使用它们。对于生成类型提供程序(SQL、实体、WSDL、配置文件),您可以从 F# 引用提供程序并使用从 C# 项目中生成的类型。
对于擦除类型提供程序,您将无法执行此操作,因为类型并不真正存在,只有 F# 可以看到它们。因此,最好的选择是用 F# 编写处理代码,并将结果作为记录集合或其他易于从 C# 使用的类型返回。
C# 实现需要什么才能使用它们?
当然,我可以只说“C# 必须支持类型提供程序!”,但这里还有一些想法。类型提供程序只是 .NET 程序集,它们不使用任何特定于 F# 的类型。该ITypeProvider
接口可以被包括 C# 在内的任何 .NET 语言使用,因此如果 C# 设计人员需要,他们可以重用所有已经为 F# 构建的优秀提供程序。
因此,将此建议提交给C# 用户的声音或在其他地方提倡(或说服 Mono 团队实施此建议!),也许它会被添加到 C# ( vNext + 1 + ...
) 中。目前,您只能获得 F# 中的所有好处。
类型提供程序工作方式的某些方面特别适合 F# 程序员的需求,但在考虑其他语言的强类型数据访问解决方案时可能不太引人注目。例如,很多 F# 编程都是在 F# Interactive 中完成的,与代码生成器(需要语言外部机制来生成源代码文件)相比,类型提供程序可以非常好地启用此工作流程。由于 C# 程序员习惯于减慢编辑-编译-运行周期,因此这在 C# 设置中可能不太重要。
从技术角度来看,我怀疑与 C# 等语言相比,F# 更普遍的类型推断可能是最大的优势。例如,如果我想将来自类型提供程序的一些数据访问逻辑包装在另一种类型中,我可以执行以下操作:
let moviesStartingWith prefix =
query {
for movie in MyDataSource.Movies do
where (movie.Title.StartsWith(prefix) }
|> Seq.toList
在 C# 中,我需要指定返回类型(例如List<DataSource.ServiceTypes.Movie>
),这最终会成为一件苦差事,这意味着即使使用 IntelliSense,我也会在提供的类型集上打点以生成签名。一组提供的值以生成查询。
当然,这也适用于类型提供者以外的领域,但我认为对于一些提供者自然生成的一些嵌套类型层次结构,这在实践中会特别痛苦,因为类型名称变得非常长。