blocks|key|1474039|text|如果您可以预料到方法名称，那么动态声明它们要比依赖method_missing要好，因为method_missing会导致性能损失。例如，假设您想要扩展一个数据库句柄，以便能够使用以下语法访问数据库视图：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1474040|selected_view_rows+=+@dbh.viewname(+:column+=>+value,+...+)|code-block|syntax|javascript|1474041|您可以提前确定数据库中的所有视图，然后迭代它们以在@dbh上创建"viewname“方法，而不是依赖于数据库句柄上的method_missing并将方法名作为视图的名称分派给数据库。|1474042|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|K|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|L|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|M|8|@]|9|@]|A|$]]|$1|I|3|-4|5|6|7|N|8|@]|9|@]|A|$]]]|J|$]]

If you can anticipate method names, it is better to dynamically declare them than to rely on method_missing because method_missing incurs a performance penalty. For example, suppose you wanted to extend a database handle to be able to access database views with this syntax:

<pre><code>selected_view_rows = @dbh.viewname( :column =&gt; value, ... )
</code></pre>

Rather than relying on method_missing on the database handle and dispatching the method name to the database as the name of a view, you could determine all the views in the database ahead of time, then iterate over them to create "viewname" methods on @dbh.

blocks|key|1474072|text|构建在Ruby上:在我尝试过的所有Pistos's+point实现上，method_missing至少比常规方法慢一个数量级。他的预测是正确的，在可能的情况下避免调用method_missing。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1474073|如果您喜欢冒险，请查看Ruby鲜为人知的Delegator类。|1474074|entityMap|0|LINK|mutability|MUTABLE|url|https://stackoverflow.com/questions/291132/methodmissing-gotchas-in-ruby#292838|1|http://ruby-doc.org/stdlib/libdoc/delegate/rdoc/index.html^0|Z|E|2B|E|H|E|0|0|K|9|1|0^^$0|@$1|2|3|4|5|6|7|R|8|@$9|S|A|T|B|C]|$9|U|A|V|B|C]]|D|@$9|W|A|X|1|Y]]|E|$]]|$1|F|3|G|5|6|7|Z|8|@]|D|@$9|10|A|11|1|12]]|E|$]]|$1|H|3|-4|5|6|7|13|8|@]|D|@]|E|$]]]|I|$J|$5|K|L|M|E|$N|O]]|P|$5|K|L|M|E|$N|Q]]]]

Building on <a href="https://stackoverflow.com/questions/291132/methodmissing-gotchas-in-ruby#292838">Pistos's point</a>: <code>method_missing</code> is at least an order of magnitude slower than regular method calling on all the Ruby implementations I've tried. He is right to anticipate when possible to avoid calls to <code>method_missing</code>.

If you're feeling adventurous, check out Ruby's little-known <a href="http://ruby-doc.org/stdlib/libdoc/delegate/rdoc/index.html" rel="nofollow noreferrer">Delegator</a> class.

blocks|key|1689111|text|如果你的方法找不到方法只查找某些方法名，如果你还没有找到你要找的方法，别忘了调用super，这样其他的方法就可以做他们想要的了。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1689112|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If your method missing method is only looking for certain method names, don't forget to call super if you haven't found what you're looking for, so that other method missings can do their thing.

blocks|key|1474257|text|另一个陷阱是：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1474258|method_missing在obj.call_method和obj.send(:call_method)中的行为不同。从本质上讲，前者遗漏了所有私有和未定义的方法，而后者则没有遗漏私有方法。|offset|length|style|CODE|1474259|因此，当有人通过send调用您的私有方法时，您的method_missing永远不会捕获调用。|1474260|entityMap^0|0|0|E|F|F|V|M|0|8|4|O|E|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@$D|N|E|O|F|G]|$D|P|E|Q|F|G]|$D|R|E|S|F|G]]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@$D|U|E|V|F|G]|$D|W|E|X|F|G]]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Y|8|@]|9|@]|A|$]]]|K|$]]

Another gotcha:

<code>method_missing</code> behaves differently between <code>obj.call_method</code> and <code>obj.send(:call_method)</code>. Essentially the former one miss all private and non-defined methods, while later one doesn't miss private methods.

So you <code>method_missing</code> will never trap the call when someone calling your private method via <code>send</code>.

blocks|key|1474363|text|詹姆斯的回答很好，但是，在现代ruby+(1.9%2B)中，正如Marc-André所说，您需要重新定义respond_to_missing?，因为它允许您访问respond_to?之上的其他方法，如返回方法本身的method(:method_name)。|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|1474364|例如，下面定义的类：|1474365|class+UserWrapper
++def+initialize
++++@json_user+=+{+first_name:+'Jean',+last_name:+'Dupont'+}
++end

++def+method_missing(sym,+*args,+&block)
++++return+@json_user[sym]+if+@json_user.keys.include?(sym)
++++super
++end

++def+respond_to_missing?(sym,+include_private+=+false)
++++@json_user.keys.include?(sym)+%7C%7C+super
++end
end|code-block|syntax|javascript|1474366|结果如下：|1474367|irb(main):015:0>+u+=+UserWrapper.new
=>+#<UserWrapper:0x00007fac7b0d3c28+@json_user={:first_name=>"Jean",+:last_name=>"Dupont"}>
irb(main):016:0>+u.first_name
=>+"Jean"
irb(main):017:0>+u.respond_to?(:first_name)
=>+true
irb(main):018:0>+u.method(:first_name)
=>+#<Method:+UserWrapper#first_name>
irb(main):019:0>+u.foo
NoMethodError+(undefined+method+`foo'+for+#<UserWrapper:0x00007fac7b0d3c28>)|1474368|因此，在覆盖method_missing时，请始终定义respond_to_missing?。|1474369|entityMap^0|1E|J|26|B|2X|K|0|0|0|0|0|6|E|R|J|0^^$0|@$1|2|3|4|5|6|7|U|8|@$9|V|A|W|B|C]|$9|X|A|Y|B|C]|$9|Z|A|10|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|11|8|@]|D|@]|E|$]]|$1|H|3|I|5|J|7|12|8|@]|D|@]|E|$K|L]]|$1|M|3|N|5|6|7|13|8|@]|D|@]|E|$]]|$1|O|3|P|5|J|7|14|8|@]|D|@]|E|$K|L]]|$1|Q|3|R|5|6|7|15|8|@$9|16|A|17|B|C]|$9|18|A|19|B|C]]|D|@]|E|$]]|$1|S|3|-4|5|6|7|1A|8|@]|D|@]|E|$]]]|T|$]]

James' answer is great but, in modern ruby (1.9+), like Marc-André is saying, you want to redefine <code>respond_to_missing?</code> because it gives you access to other methods on top of <code>respond_to?</code>, like <code>method(:method_name)</code>returning the method itself.

Example, the defined following class:

<pre class="lang-rb prettyprint-override"><code>class UserWrapper
 def initialize
 @json_user = { first_name: 'Jean', last_name: 'Dupont' }
 end

 def method_missing(sym, *args, &amp;block)
 return @json_user[sym] if @json_user.keys.include?(sym)
 super
 end

 def respond_to_missing?(sym, include_private = false)
 @json_user.keys.include?(sym) || super
 end
end
</code></pre>

Results in:

<pre><code>irb(main):015:0&gt; u = UserWrapper.new
=&gt; #&lt;UserWrapper:0x00007fac7b0d3c28 @json_user={:first_name=&gt;"Jean", :last_name=&gt;"Dupont"}&gt;
irb(main):016:0&gt; u.first_name
=&gt; "Jean"
irb(main):017:0&gt; u.respond_to?(:first_name)
=&gt; true
irb(main):018:0&gt; u.method(:first_name)
=&gt; #&lt;Method: UserWrapper#first_name&gt;
irb(main):019:0&gt; u.foo
NoMethodError (undefined method `foo' for #&lt;UserWrapper:0x00007fac7b0d3c28&gt;)
</code></pre>

So, always define <code>respond_to_missing?</code> when overriding <code>method_missing</code>.

Are there any things to be careful about when defining the <code>method_missing</code> method in Ruby? I'm wondering whether there are some not-so-obvious interactions from inheritance, exception throwing, performance, or anything else.

method_missing gotchas in Ruby

Ruby语言

数据库

在Ruby语言中定义method_missing方法时有什么需要注意的地方吗？我想知道是否有一些不太明显的交互来自继承、异常抛出、性能或其他任何东西。

问Ruby语言中的method_missing陷阱
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Ruby语言中的method_missing陷阱EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问Ruby语言中的method_missing陷阱
EN