10

是否有计划实现类似于 CoffeeScript 在方法参数列表中指定实例变量名称的 ruby​​ 行为？像

class User
  def initialize(@name, age)
    # @name is set implicitly, but @age isn't.
    # the local variable "age" will be set, just like it currently works.
  end
end

我知道这个问题：在 Ruby 中，我可以在初始化方法中以某种方式自动填充实例变量吗？，但是所有的解决方案（包括我自己的）似乎都不符合 ruby​​ 的简单哲学。

而且，这种行为会有什么缺点吗？

更新

造成这种情况的原因之一是 ruby​​ 社区的 DRY（不要重复自己）哲学。我经常发现自己需要重复参数变量的名称，因为我希望将它分配给同名的实例变量。

def initialize(name)
  # not DRY
  @name = name
end

我能想到的一个缺点是，如果一个方法没有主体，它可能看起来好像什么都不做。如果您正在快速扫描，这可能看起来像是无操作。但我认为给定时间，我们可以适应。

另一个缺点：如果您在正文中设置其他实例变量，并且您尝试通过将所有赋值放在开头来使其可读，则可能需要更多的认知“能力”才能看到参数列表中也发生了赋值。但是我认为这并不比看到一个常量或方法调用并不得不跳转到它的定义更难。

# notice: instance var assignments are happening in 2 places! 
def initialize(@name)
  @errors = []
end
4

3 回答 3

4

经过一番思考，我想知道是否可以从 ruby​​ 方法中实际获取参数名称。如果是这样，我可以使用像“iv_”这样的特殊参数前缀来指示应该将哪些参数设置为实例变量。

并且有可能：如何使用反射获取参数名称。

是的！所以我也许可以写一个模块来为我处理这个。然后我被卡住了，因为如果我调用模块的辅助方法，它不知道参数的值，因为它们是调用者的本地。啊，但是 ruby​​ 有 Binding 对象。

这是模块（仅限 ruby​​ 1.9）：

module InstanceVarsFromArgsSlurper
  # arg_prefix must be a valid local variable name, and I strongly suggest
  # ending it with an underscore for readability of the slurped args.
  def self.enable_for(mod, arg_prefix)
    raise ArgumentError, "invalid prefix name" if arg_prefix =~ /[^a-z0-9_]/i
    mod.send(:include, self)
    mod.instance_variable_set(:@instance_vars_from_args_slurper_prefix, arg_prefix.to_s)
  end

  def slurp_args(binding)
    defined_prefix = self.class.instance_variable_get(:@instance_vars_from_args_slurper_prefix)
    method_name = caller[0][/`.*?'/][1..-2]
    param_names = method(method_name).parameters.map{|p| p.last.to_s }
    param_names.each do |pname|
      # starts with and longer than prefix
      if pname.start_with?(defined_prefix) and (pname <=> defined_prefix) == 1
        ivar_name = pname[defined_prefix.size .. -1]
        eval "@#{ivar_name} = #{pname}", binding
      end
    end
    nil
  end
end

这是用法：

class User
  InstanceVarsFromArgsSlurper.enable_for(self, 'iv_')

  def initialize(iv_name, age)
    slurp_args(binding)  # this line does all the heavy lifting
    p [:iv_name, iv_name]
    p [:age, age]
    p [:@name, @name]
    p [:@age, @age]
  end
end

user = User.new("Methuselah", 969)
p user

输出：

[:iv_name, "Methuselah"]
[:age, 969]
[:@name, "Methuselah"]
[:@age, nil]
#<User:0x00000101089448 @name="Methuselah">

它不会让你有一个空的方法体，但它是 DRY。我确信它可以通过仅指定哪些方法应该具有此行为（通过 alias_method 实现）而不是在每个方法中调用 slurp_args 来进一步增强 - 规范必须在定义所有方法之后。

请注意，模块和辅助方法名称可能会得到改进。我只是使用了想到的第一件事。

于 2012-06-02T22:13:08.283 回答
2

实际上...

class User
  define_method(:initialize) { |@name| }
end

User.new(:name).instance_variable_get :@name
# => :name

适用于 1.8.7，但不适用于 1.9.3。现在，我从哪里得知这...

于 2012-06-02T02:36:39.613 回答
0

我想你回答了你自己的问题，它不符合红宝石的简单哲学。它会增加方法中处理参数的额外复杂性，并将管理变量的逻辑上移到方法参数中。我可以看到这样的论点，即它使代码的可读性降低了，但它确实让我觉得不是很冗长。

@ 参数必须应对的一些场景：

def initialize( first, last, @scope, @opts = {} )

def search( @query, condition )

def ratchet( @*arg  )

所有这些场景都应该有效吗？只是initialize？@*arg在我看来，这似乎特别冒险。所有这些规则和排除使 Ruby 语言更加复杂。为了自动实例变量的好处，我认为这不值得。

于 2012-06-01T20:32:16.250 回答