我有一个问题是理解F#中"null"和Option的共存.在一本书中,我已经读过,在F#中,null值不是一个合适的值,因为这样F#消除了过多的空值检查.但它仍允许F#中的空初始化引用.换句话说,你可以拥有空值,但你没有武器来保护自己.为什么不用Options完全替换null.是因为.NET库或语言的兼容性问题还存在吗?如果是,你能给出一个例子,说明为什么它不能被Option取代?
F#null尽可能避免使用,但它存在于.NET生态系统中,所以它无法完全避免它.在一个完美的世界里,没有null价值观,但你有时需要它们.
例如,您可能需要将.NET方法null作为参数调用,并且可能需要检查.NET方法调用的结果是否为null.
F#解决这个问题的方式是:
在处理来自.NET的类型时使用Null(当您在.NET中声明类型的值或参数时,可以使用null该类型的值;您可以测试它是否等于null)
使用F#类型时需要选项,因为F#中声明的类型的值不能null(并且编译器禁止使用null这些类型的值).
在F#编程中,您也可以在使用.NET类型时使用选项(如果您可以控制其值的创建方式).您永远不会创造null价值,然后使用选项来保证您将始终正确处理缺失值.
这是唯一的选择.如果您想在访问.NET API时隐式地查看所有类型作为选项,几乎每个方法都是这样的:
option<Control> GetNextChild(option<Form> form, option<Control> current);
Run Code Online (Sandbox Code Playgroud)
用这样的API编程会非常痛苦.
| 归档时间: |
|
| 查看次数: |
685 次 |
| 最近记录: |