环境/*.rb 中的配置符号是如何解析的

这就是一个典型的config/environments/*.rb文件开始：

MyApp::Application.configure do
  config.cache_classes = false
  ...
end

该块传递给configure取消引用该符号config这显然是不受约束的。这在技术上是如何运作的？块/Proc/lambda 中使用的符号应绑定在其声明的上下文中，而不是在调用站点的动态作用域中解析。

一个相关的问题是，到底在哪里Application.configure方法声明？它也不在application.rb https://raw.github.com/rails/rails/b04ec2764f62d5734c57959e2f00f9ef4345d52e/railties/lib/rails/application.rb, engine.rb https://raw.github.com/rails/rails/b04ec2764f62d5734c57959e2f00f9ef4345d52e/railties/lib/rails/engine.rb, or railtie.rb https://raw.github.com/rails/rails/b04ec2764f62d5734c57959e2f00f9ef4345d52e/railties/lib/rails/railtie.rb。也许如果我设法找到这种方法，我就能找到我的主要问题的答案。

也相关，我研究过Rails 初始化过程 http://guides.rubyonrails.org/initialization.html在令人难以忍受的细节中，我什至找不到任何提及config/environments/*.rb文件。如果我知道 init 过程如何处理这些文件，可能会对此有所启发。

这是一个方法config in Rails::Application在 Railties 宝石中lib/rails/application.rb它返回一个实例Application::Configuration，定义于lib/rails/application/configuration.rb.

方法configure被贡献于Railtie来自autoload教育模块Configurable, lib/rails/railtie/configurable，并定义为

def configure(&block)
  class_eval(&block)
end

这解释了为什么阻止configure接受可以解决config象征。注意class_eval是使这项工作有效的另一个红宝石魔法：它重新绑定传入的块self调用站点类的符号。

检查引导过程部分第一个文件中的注释，其中解释了所有这些优点的来源、方式和顺序，包括如何/config/environments目录已处理。