Playlouder MSP

Can I just say that, after spending the better part of a day over the last week having to hack around its mysterious and messy guts, ActiveSupport’s dependency auto-class-loading code is officially Too Damn Magical For Its Own Good. Whenever you have non-trivial dependencies between classes and modules in your project, mysterious class loading bugs will often cripple your code in hard-to-track-down ways. Judicious use of ‘require_dependency’ is your friend here, although too much use of it will lead to further problems. Latent cyclic dependencies are often the culprit, and can be fixed or hacked around, but discovering them from the rather opaque exception (‘expected foo.rb to define Foo’) and stack trace can be hard.

The following Rails bug: http://dev.rubyonrails.org/ticket/6001 doesn’t exactly help matters – if any of your classes refer to ApplicationController and are themselves referred to (and hence auto-loaded) during the environment loading process (environment.rb etc), this will lead to problems, as Rails does a straight ruby ‘require’ on application.rb after environment.rb has run. As it’s not called application_controller.rb, the auto class loading doesn’t work normally for it, which can cause further problems if ApplicationController gets tied up in any other dynamic dependency chain reloading issues.

Now obviously these issues are necessarily complex – loading classes from files with complex dependencies is a tricky problem when programming with a dynamic language. Although I can’t bring myself to use Squeak, the ‘directly edit the live code image’ approach Smalltalk/Squeak takes seems to avoid this problem of dynamically reloading classes from files during development. It’s something that needs to be thought about at the level of the Ruby language, and while the ActiveSupport hacks are admirable in their cleverness, cleverness that only works cleanly in the simplest cases is a mixed blessing.