我正在学习Ruby,我有一个关于打字的重大概念问题。请允许我详细说明为什么我不了解范式。如何使用Ruby Duck Typing
假设我是Ruby中的简洁代码的方法链接。我必须精确地知道链中每个方法调用的返回类型,否则我不知道下一个链接上有哪些方法可用。我每次都必须检查方法文档吗?我遇到了这个不断运行的教程练习。看来我坚持一个参考过程,推断,运行,失败,修复,重复以获得代码运行,而不是知道我在编码期间正在处理的内容。这在Ruby的直觉性承诺面前飞来飞去。
说我正在使用第三方库,我再一次需要知道哪些类型允许传递参数,否则我会失败。我可以看看代码,但是可能会有也可能没有任何关于该方法所期待的类型的评论或声明。我理解你基于方法的代码是可用的对象,而不是类型。但是,我必须确定无论我传递的参数是否具有库所需的所有方法,所以我仍然需要进行类型检查。我是否希望并祈祷一切都在接口上正确记录,以便我知道是否需要给出字符串,哈希,类等。
如果我查看方法的来源,我可以得到一个被调用的方法列表并推断出预期的类型,但我必须执行分析。
Ruby and duck typing: design by contract impossible?
在前面的计算器问题的讨论没有真正回答不是“有你必须遵循流程”和这些进程似乎并不为标准的其它任何东西,每个人都有不同的意见遵循什么程序,以及该语言的执行力度为零。方法验证?测试驱动设计?记录的API?严格的方法命名约定?标准是什么,谁决定它?我遵循什么?这些指导方针是否可以解决这个问题https://stackoverflow.com/questions/616037/ruby-coding-style-guidelines?有编辑帮忙吗?
从概念上讲,我也没有得到好处。您需要知道所调用的任何方法需要哪些方法,因此无论您在编写任何代码时都正在输入内容。除非您决定对其进行记录,否则您只是没有明确告知该语言或任何其他人。然后,你被困在做所有类型检查在运行时而不是在编码过程中。我已经完成了PHP和Python编程,但我也不明白。
我错过了什么或不理解?请帮我理解这个范例。
鸭子打字有一定的优势,但当然也有缺点。我可以将* any *对象传递给一个方法'foo(a)',它只要调用'a.responds_to?(:bar)'就可以调用'a.bar'。这很好。没有界面,没有泛型,只需添加一个'bar'方法即可。当然,静态打字也有很多优点。听起来你只需要一些Ruby方式的经验来欣赏两者。也听起来像你可能被intellisense(或类似的功能)有点被宠坏了。许多(*许多*)我们必须尽早且经常地检查文档。 –
直觉是训练的结果,所以没有直觉,直到你训练自己使用它。 –
这个问题患有“TL; DR”。它会帮助你总结它,并抛弃其他方面,否则它太广泛了。 “这直接面对Ruby对直觉的承诺。”对谁是直观的? Matz说,它的设计对他来说很直观,而且他认为对于那些已经充分使用它的人来说,这会变得直观。创建一种立即对所有人都直观的语言是不可能的,所以他的目标就是点亮。 –