ruby - 有人可以帮我理解以下 Ruby 片段吗？

Question

我最近在 Tomcat 的 JRuby 上运行 Sinatra 时遇到了 permgen 内存泄漏。问题与 Sinatra 用来支持各种模板选项的 Tilt 库有关。旧代码(此处未包含)导致内存泄漏。新代码(下面)没有，事实上我看到 permgen GC 现在正在工作。

Ruby 应该是 self 描述的，但我无法通过阅读来理解这段代码。有嵌套类评估。为什么？为什么要定义一个方法然后解除绑定(bind)？

为什么编译一堆模板并保留它们以供重复使用的代码看起来如此复杂？

另外:如果有任何 GitHub 员工在看这个问题，您能否向 GitHub 添加一些功能，允许用户在代码片段中插入问题？

(此代码取自 https://github.com/rtomayko/tilt/blob/master/lib/tilt.rb)

def compile_template_method(locals)  
  source, offset = precompiled(locals)  
  offset += 5  
  method_name = "__tilt_#{Thread.current.object_id.abs}"  
  Object.class_eval <<-RUBY, eval_file, line - offset  
    #{extract_magic_comment source}  
    TOPOBJECT.class_eval do  
      def #{method_name}(locals)    
        Thread.current[:tilt_vars] = [self, locals]  
        class << self  
          this, locals = Thread.current[:tilt_vars]  
          this.instance_eval do  
            #{source}  
          end  
        end  
      end  
    end  
  RUBY  
  unbind_compiled_method(method_name)  
end  

Answer 1

There are nested class evals. Why?

与您合理期望的优雅的自描述代码不同，此方法看起来像是来自久经沙场、经过修复和打补丁的生产代码(因此也许我们可以稍微原谅他们)。

那么为什么要进行两次评估？在评估第二个嵌套的“真实”模板方法代码之前，要评估的代码必须以正确的源编码为前缀，该编码可能已在模板文件中定义为“魔术注释”。

一旦字符串编码设置正确，就可以尝试真正的class_eval了。另一种说法可能是“这是编写源代码的源代码”!

据推测，这是为了修复 Ruby 1.9 中可能出现的兼容性问题，其中正在编译的模板可能包含与 Tilt 库源代码本身的编码(US-ASCII 编码)不同的字符编码 (UTF-8) )，这将导致模板字符串的评估不正确(因为字符串编码已经在调用模板文件的主机代码中设置)。

Why is a method being defined and then unbound?

澄清一下:在 Ruby 中，unbound 与 undefined 不同。

未绑定(bind)方法作为可以调用的 UnboundMethod 类型的自由方法对象存在，尽管它们不再与特定对象相关联。未绑定(bind)的方法不再有接收者。

为了创建一个未绑定(bind)的方法，它首先必须绑定(bind)到(针对)一个对象。这就是编译后的模板方法很快从顶级对象中删除的原因，因为它只是生成未绑定(bind)方法所需的临时安排。

此技术用于使使用针对给定类的不同实例的编译模板成为可能，而无需以任何可见或永久的方式更改根对象或第三方开发人员的客户端类。

通过取消编译模板方法与特定客户端代码对象的关联，编译模板方法可以在以后调用使用该类型对象的模板期间重新绑定(bind)到该对象类的新实例。

例如，给定以下 ERB 模板:

<p>Hello <%= @name %></p>

...以及以下调用代码:

scott = Person.new
scott.name = "Scott"
output = template.render(scott)
=> "<p>Hello Scott</p>"

在第一次渲染期间，模板根据 TOPOBJECT 对象的实例进行评估和编译。编译后的模板方法将被命名为类似“__tilt_2151955260”的名称。然后，此方法将被解除绑定(bind)以再次用于类型 TOPOBJECT 的所有实例(根据 Ruby 版本，它只是 Object 或 BasicObject)，因此可以用于任何客户端对象类型。

下次渲染模板时，编译后的模板方法与 TOPOBJECT 的 'baq' 实例绑定(bind):

baq = Person.new
baq.name = "Baq"
output = template.render(baq)

在底层，当 template.render(baq) 被调用时，未绑定(bind)的编译模板方法被绑定(bind)到 Person 的“baq”实例:

__tilt_2151955260.bind(baq).call

不必每次都调用 class_eval 可显着提高性能。

Why is code that compiles a bunch of templates and keeps them around for re-use so complicated looking?

我的评估是，虽然代码实现乍一看确实看起来不必要地复杂，但这些间接层在框架代码中通常是必需的，旨在使公共(public) API 变得非常简单并且可以为成千上万的其他开发人员使用，即使它是以必须维护它的少数开发人员为代价的。

代码的复杂性(双重 eval 嵌套)也增加了，这是由于在许多不同的语言环境中使用的 API 以及来自世界各地的许多编码所引起的现实世界问题。

脚注:问题中提到的模板类已被重构到一个单独的文件中 github.com/rtomayko/tilt/blob/master/lib/tilt/template.rb