Ruby 参数类型确认

发布于 2024-11-14 19:17:57 字数 401 浏览 4 评论 0原文

来自 Java 背景的我对 Ruby 对其方法参数完全漠不关心的态度感到有点不安。在 Java 中,我可以保证参数 x 是该方法正常工作所需的类型,但在 Ruby 中,我无法保证 x 是整数、字符串或其他任何类型。

示例:如果我想用Java编写一个absolute_value方法,标题将类似于

public static int absoluteValue(int x)

在Ruby中,它会类似于

def self.absolute_value(x)

在这个示例中,在Java代码中我可以完全确定传入的参数不是“Happy”生日!”但在 Ruby 代码中我不知道这一点。如何在 Ruby 中防止出现这种情况,以便代码不会在运行时崩溃?

Coming from a Java background, I am a little perturbed by Ruby's completely blasé attitude toward its method parameters. Whereas in Java I could guarantee that parameter x was the type necessary for the method to work properly, in Ruby I have no way of guaranteeing that x is an integer, a string, or anything else for that matter.

Example: if I wanted to write an absolute_value method in Java, the header would be something like

public static int absoluteValue(int x)

In Ruby it would be something like

def self.absolute_value(x)

In this example, in the Java code I can be totally sure that the parameter being passed in isn't "Happy Birthday!" but in the Ruby code I don't know that. How do I prevent this situation in Ruby so the code doesn't crash at Runtime?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

夏の忆 2024-11-21 19:17:57

呵呵,欢迎来到鲁比。过去几年我也从事过 Java 工作,当时我真的很喜欢 Java。

现在,认为 Ruby 缺乏类型检查是不正确的。它至少具有与 Java 一样多的类型检查,只是类型允许更改,因此检查是在运行时完成的。

另外,旧语言中所有令人崩溃的声明样板都很烦人。一个经过类型检查的应用程序如果没有及时完成而无法发挥作用,对任何人都没有任何好处。过于冗长而难以阅读的类型检查程序可能会过时。

如果您第一次运行 Ruby 程序时未检查某个类型,则您的测试很可能会覆盖该类型。

但是,如果您不测试它,您就不知道它是否有效,因此方法调用类型符合的抽象知识不会像您想象的那么有用。

无论如何,Ruby 作为一种语言目前已经很好地证明了自己。作为一个现实生活中的平台,RoR 在速度和内存使用方面都存在一些性能问题,但我不知道有任何项目抱怨动态类型并希望他们能够通过使用一些旧的冗长语言来获取 RSI。

Heh, welcome to Ruby. I too worked in Java in certain past years and I really loved Java at the time.

Now, it's not correct to think of Ruby as lacking type checking. It has at least as much type checking as Java, it's just that types are allowed to change and so the checks are done at runtime.

Plus, all that crushing declaration boilerplate in the old languages is annoying. A type-checked application that doesn't get finished in time to be useful does no one any good. A type-checked program that's too verbose to read is likely to become obsolete.

And if a type doesn't get checked the first time you run your Ruby program, it may well be covered by your tests.

But if you don't test it, you have no idea if it works anyway, so the abstract knowledge that the method call types conform would not be nearly as helpful as you might imagine.

In any case, Ruby has proven itself pretty well at this point as a language. As a real-life platform, RoR has some issues with performance, both in speed and in memory use, but I don't know of any projects complaining about the dynamic typing and wishing they were slogging through getting RSI with some old verbose language.

不即不离 2024-11-21 19:17:57

欢迎来到鲁比,克瓦斯。希望您能学会喜欢鸭子打字。通过编写测试,而不是依赖类型检查和编译,您可以对 Ruby 代码充满信心。您无需定义类型即可获得速度、灵活性和可读性。

Welcome to Ruby, Kvass. Hopefully you'll learn to love duck typing. You gain confidence in your code in Ruby by writing tests, not depending on type checking and compilation. You gain speed, flexibility, and readability by not having to define the types.

枕头说它不想醒 2024-11-21 19:17:57

如果你想活命,就跟我来吧。

a="String"
puts a.kind_of? Integer  # false
puts a.kind_of? String   # true

a=10
puts a.kind_of? Integer  # true
puts a.kind_of? String   # false

Come with me if you want to live.

a="String"
puts a.kind_of? Integer  # false
puts a.kind_of? String   # true

a=10
puts a.kind_of? Integer  # true
puts a.kind_of? String   # false
长亭外,古道边 2024-11-21 19:17:57

Ruby(几乎?)总是被解释的,因此方法头中指定的类型检查无论如何都会在运行时崩溃。 “鸭子打字”行为(其中操作类型检查所操作的对象是否具有正确的权限) method) 是 Ruby 习惯用法的一部分,您不应该尝试用 Ruby 编写 Java。改为学习编写 Ruby 代码。

Ruby is (almost?) always interpreted, so a type check specified in a method header will crash at runtime anyway. The "duck typing" behaviour (where an operation type checks if the object being acted upon has the right method) is part of the idiom of Ruby, and you shouldn't try to write Java in Ruby. Learn to write Ruby code instead.

盗心人 2024-11-21 19:17:57

您可以进行最低水平的方法测试,同时仍然保持鸭子类型。使用《The ruby​​ programming language》一书中的示例

def +(other)
  raise TypeError, "Point-like argument expected" unless other.respond_to? :x and other.respond_to? :y
  Point.new(@x + other.x, @y + other.y)
end

该示例用于在 Point 类上实现“+”操作,该操作与 (x,y) 坐标一起使用。他们没有执行 other.is_a?(Point) - 他们测试了该方法的实现,对我来说这似乎是一个不错的选择。人们可能会争辩说,“其他”对象可能具有 x 和 y 属性,表示不同的东西,尽管正确的论点忽略了我只是指出中间立场的这一点。我的方法也倾向于直接进行加法,如果有人传递了错误的类型,则会失败。

You can do a minimal level of method testing while still maintaining duck typing. To use the example from the book "The ruby programming language"

def +(other)
  raise TypeError, "Point-like argument expected" unless other.respond_to? :x and other.respond_to? :y
  Point.new(@x + other.x, @y + other.y)
end

This example is used to implement "+" operation on Point class which works with (x,y) cordinates. Rather than doing a other.is_a?(Point) - they've tested the method's implemented, which to me seems like a good option. One can argue that the "other" object might have x and y attrs meaning something different, which although a correct argument misses the point that I am just pointing to a middle ground. My approach is also tilted towards doing the addition directly and failing if someone passes a wrong type.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文