天生一对

Born to be together，这句也是Apple以前iTune和iPod的广告词。不过这里是用来比喻两个语言特性：类型推断和命名参数。

自ML诞生的类型推断技术似乎随着C#3的宣传日渐进入主流视野，一些新语言如D,Scala也实现了所谓“局部类型推断”（只简化声明，但不推断函数接口）。类型推断简化了大量不必要的类型声明，使代码获得动态脚本语言一样的感观，同时有获得编译期的类型检查和运行时的性能。不过在可读性上或多或少有点影响，有几种解决办法：
1）添加注释，以后注释和代码的同步维护负担重，不理想。
2）添加类型声明，像Haskell那样，繁琐。当然显式类型声明有时是用来约束更紧的类型。
3）更具说明性的参数命名＋命名参数，这也是为什么动态语言没有类型声明也不会感觉不可读的问题，甚至比静态语言在调用函数的时候更可读。某种程度上VB发明的匈牙利命名法也不失为一种增进动态语言可读性的办法。

命名参数有如下好处：
－不用再硬记参数顺序了，没有IDE提示也能过日子
－相当于调用时的参数描述文档
－一般支持命名参数的语言都会支持可选参数（这两个也是天生一对），可选参数的意义不仅是简化函数调用，而且让参数API可扩展又不影响已有代码。可选参数还消灭了方法重载（overload）的必要。

埃，这么多好处，没有命名参数的语言真是没法活了。

说道命名参数的实现，一般分两类：一种是语法级实现如Python，Ocaml；一种是用hash/record或某种复合数据结构模拟，如Ruby和Haskell。

评论

4 楼 cookoo 2007-06-25  

相等问题：因为OO中大量的sub typing这个问题确实挺难，但并非不可解决， 只不过推断出的类型可能过于宽泛有时还得显式约束一下。F#的OO模型完全和C#等价，事实上.Net上的泛型还是F#首先实现的。还有更多的例子，如Haskell衍生OO版本O'Haskell和彻底OO的flash语言Haxe。

命名参数我是从可读性角度考虑的，你可以看看wxHaskell的接口就是用record的风格。否则一个窗口控件属性一堆，每次生成不管有的没的都要把属性参数输入一遍实在难以想象。当然这是风格问题，不是语言强制的，虽然我认为是个好风格。

3 楼 Lich_Ray 2007-06-25  

引用

Ocaml和F#...

注意我的原话“无法和基于命令式风格的面向对象范式共存”——它们中有 class，但其实用的是保护性质的（函数式风格的）一种类型组织手段；静态类型推断无法和基于命令式风格的面向对象范式共存的重要原因在于不能正确处理相等这个问题，而在函数式语言中这不是个问题。
apply()该过之后感觉在语言自足性上有问题；Haskell 这么嚣张，但在这个问题上还是没有越雷池一步，很明智。

2 楼 cookoo 2007-06-25  

不会吧，Ocaml和F#都说明type inference和OO是可以共存的。至于apply()，如果是第二种即用hash/dict来实现命名参数的就可以使用啊，甚至在已经有内建语法的Python和Ocaml里也能这么干，当然风格受点影响。

1 楼 Lich_Ray 2007-06-25  

静态类型推断无法和基于命令式风格的面向对象范式共存。在 D 中加入类型推断纯属乱弹琴。
PS: 命名参数不是终极解决方案，至少无法和 apply() 共存。可能，语言设计者们参数指定手段方面考虑的还不够。