新手问题 关于阅读 / 查看 「动态语言」源代码,这个问题怎么解决?

jcd · 2015年03月14日 · 最后由 billy 回复于 2015年04月14日 · 2527 次阅读

动态语言,比如 ruby. 阅读源代码总是挺虐心的,因为你不能轻易知道方法/函数的返回值和参数分别是什么数据类型的! 有时候甚至看遍整个方法的代码去猜测参数是什么类型的,返回值又是什么类型的。 所以有时候可能就多此一举地在定义方法时描述一下:

# params: A: string, B: float
# return: instance of ClassX
def wtf(A, B)
...
end

# 该传 interger 的  id 呢还是 string 的  id ?
def process(id)
...
end

可不是每个人都那么有闲功夫的。还是这就是个无奈之举,你们平时是怎么解决的?

虽然这个问题对于 ruby 这种纯 OO 比其它不纯 OO 的语言要轻松些。

分享一个链接: http://blog.codeclimate.com/blog/2014/05/06/gradual-type-checking-for-ruby/


补充:有人出现成方案了:https://github.com/gogotanaka/Rubype

调用一下就知道了,再说,一般文档都有写的

有人出现成方案了:https://github.com/gogotanaka/Rubype 虽然有点繁琐,但是很不错!真的。

我觉得这是个伪问题。

参数一定会声明的有意义,例如:

Array#abbrev(pattern = nil)

我马上就知道这个 pattern 是什么类型了啊,反而像静态语言那种太繁琐。

最近看到 coursera 介绍 scala,据说重构方便。这方面 Ruby 也缺乏支持。 感觉 Ruby 对中小型项目还是不错的,比较轻便。大项目会有诸多不便。

动手操作一下 分别传不同的参数,.class 不就知道了嘛

小小的建议下:与其痛苦地纠结变量的数据类型,还不如像 Duck Typing 那样只关心行为。

我记得 Ruby 的文档都是会给使用范例的,类型什么的文档都说得很清楚。

我感觉 Rubype 并不是真正意义上的 Gradual Type Checking,它只能算是一个 framework,本质上也是一个动态类型检查,只不过它把本来应该由程序员编写的运行时类型检查,通过声明式(Declarative)的方式让解释器执行罢了。

我认为引入类型系统,一方面是为了确保程序的正确性(强类型),另一方面是加速程序的运行(尽早确定操作符,而不是动态派发)。但从 Benchmark 的结果来看,如果不再解释器的层次上实现 Type Annotation 和 Type Checking,实际应用的前途不太大啊。

私货:http://deathking.github.io/2015/04/10/what-is-gradual-typing/

那个 Rubype 在每个 method 下面都加那么一行,看着就醉了,还真不如直接写 Java。

就你的具体问题来说:

wft这个方法确实可以加一点说明,因为 float 非常规。但是,与其写成无意义的参数名wft(A, B)加说明,不如直接写成wft(foo_string, bar_float), 这样不用任何说明别人都能看懂。

关于process(id),如果这个方法是你写的,而你估计有可能出现 id 为 string 的情况,你应该在方法的首行加一个保护, id = id.to_i。如果基本没有这个可能则不用麻烦。

如果这个方法是别人的,直接传送 Fixnum,无须顾虑。参数写了 id 就已经表明了作者的意图是接受 integer。如果不是,你可以去批评他。

需要 登录 后方可回复, 如果你还没有账号请 注册新账号