question about idiom for loading files in initializer.rb

rubyonrails-core
1

Hi --

This started as a question in ruby-talk. It's about this line of code:

eval(IO.read(init_path), binding, init_path)

This idiom appears in initializer.rb, in v1.2.3, for loading environment files and plugin init files. (On Edge, the plugin stuff is moved to another file, but the same idiom's still used in that file, and you'll see it used for the env files in initializer.rb on Edge as well.)

The question was, why use this idiom instead of load or require?

My assumption is that the answer is this idiom gives you flexible bindings, but if anyone could verify that, or correct me, I'd totally appreciate it. I don't actually see the binding passed being declared anywhere, so it kind of puzzles me.

Thanks, Giles

2

Giles,

You're on the right track with the binding. Evaling against the current binding gives (int this case) your environment file access to the "config" local. Check Kernel#binding in the Ruby core docs for a bit more enlightenment.

~ j.

3

I think it's so some local variables are available in the init.rb file: directory, lib_path, etc. Actually, they're now methods of the Rails::Plugin class.

4

That was exactly the case. Try to share local variables between files using load and require to understand why.

5

The question was, why use this idiom instead of load or require?

So that the code gets access to config.*, using require would be a different scope.

6

I think it's so some local variables are available in the init.rb file: directory, lib_path, etc. Actually, they're now methods of the Rails::Plugin class.

This suggests that you could refactor it, but you can't actually remove it completely, because it's also used in the code which brings in environment files.

The code is kinda repetitive:

eval(IO.read(init_path), binding, init_path) # plugins eval(IO.read(configuration.environment_path), binding, configuration.environment_path) # env files

So I made a tiny refactoring patch:

http://dev.rubyonrails.org/ticket/9128

Gracias senores, Giles