Skip to main content

Mobomo webinars-now on demand! | learn more.

As the focus on multithreaded Ruby grows and grows, code autoloaders seem to be a less and less manageable solution. By the same token, it can be pretty ugly to manually require dozens of files or come up with complex schemes for requiring files.

Node.js has a pattern that I personally enjoy: if you require a directory, it will automatically look for a file called index.js in that directory and require that if present. This, to me, presents a simple, usable way to manage complex require schemes. On a whim, I decided to see how easy it would be to implement such a pattern in Ruby. Turns out it's not hard:

def require(path)     super rescue LoadError => e     searches = $:.map{|dir| File.join(dir, path)}     searches.each do |search|         if File.exist?(path + "/index.rb")             return require path + "/index"         end     end     raise e end

This implementation is simple, naive, and likely extremely dangerous in ways I don't understand. What it does is simply take the path specified in the require call and walk through the load path, looking for an index.rb file in a directory denoted by the path. If it finds one, it requires that and returns. If it doesn't, it raises the standard LoadError.

I'm not an expert on Ruby's file loading internals, which is why I spent five minutes making this hack method instead of trying to come up with an actual elegant solution. What I want to do, however, is start a conversation about whether this pattern makes sense or has a place in Rubyland. I think it would be nice to have a structure like this:

# In e.g. "application.rb"  require 'app/models'   # In app/models/index.rb  require 'app/models/user' require 'app/models/post' # ...

It keeps everything explicit (I've become a big fan of explicit requires as opposed to directory or name-based autoloading) while still keeping a syntactically nice require call that describes what is happening quite well.

So what do you think? Is this a pattern worth exploring? Is this maybe a gem waiting to be written? Should it be made part of the core language? Let me know in the comments below or tweet @intridea with your thoughts!

Categories
Author

Hey RailsConf goers! You won't want to miss Jerry Cheung, co-author of (the just-released) MacRuby in Action book and Senior Engineer at Intridea present "Evented Ruby vs Node.js" Tuesday afternoon!

While Node.js is the hot new kid on the block, evented libraries like EventMachine for Ruby and Twisted for Python have existed for a long time. When does it make sense to use one over the other? What are the advantages and disadvantages to using node over ruby? In this talk, you will learn how to get the same power of concurrency enjoyed by Node.js while continuing to write in the language you know and love. Topics covered will include pubsub with redis or faye, building evented rack applications, and running evented applications alongside existing Rails apps.

Jerry will be in Salon K at 2:30 pm tomorrow.

Keep it weird, Austin Rails!

Categories
Author
1
Subscribe to Nodejs