1

It seems like a common problem in Ruby applications in typical long-running process environments such as the rails server, that class-reloading to ease development pain is a difficult, but important problem to solve.

It strikes me that the language knows best what constants are defined by the stdlib, and is perfectly placed to know what constants were loaded from what files and when, and of course to offer to re-load them.

There are come complex cases where by require 'foo', you also define Bar, but that isn't too challenging to track, and furthermore cases where define_const has been used also muddy things up. Threaded loading is yet another problem, but I can really see a case for allowing threads to re-load themselves from the current state of the disk's files. (Faster test server would be #1 thought)

It seems like it should be a language feature, and not something that many, many different people need to roll solutions for.

So in summary, why is it that this isn't a language feature? It seems like it should be, although the usage profile is almost exclusively limited to long running dev servers.

The other question here could be "why doesn't Rails use a built-in DRB model for making the dev server fast, and skip all the class reloading", that's also an interesting discussion, but not for now.

Lee Hambley
  • 6,270
  • 5
  • 49
  • 81

1 Answers1

0

To be able to automatically re-load a class you'll need to know how that class came to be constructed. Given how dynamic Ruby is, this is only easy in the most trivial of cases. It is common enough to have a class that's extended and altered significantly before it ends up in its final form. Determining the steps involved to recreate a class is not easy, and tracking these could be a severe performance drag.

A lot of this boils down to the fact that a Class is a collection of methods, instance variables, class variables, constants, and other modules and classes. Unlike more statically typed languages like C++, these can and will be declared at any time, in any place, for any reason. The state of the class is not something that can simply be re-generated.

The way Rails goes about reloading classes is to perform a number of tricks to ensure the class in question can be disposed of and reloaded. Rails also has to provide several hooks to notify extensions that a class is being reloaded so they can re-do their operations on it once it's been rebuilt otherwise many extensions would load only once.

In short, what seems superficially trivial turns out to be very tricky indeed.

tadman
  • 208,517
  • 23
  • 234
  • 262
  • It certainly seems tricky, but still something that the language, rather than multiple framework authors ought to solve.. thanks for the answer. – Lee Hambley Sep 27 '12 at 15:46
  • If you're insatiably curious, you might want to look at some of the [magic](http://rkh.im/code-reloading) going on inside ActiveSupport. – tadman Sep 27 '12 at 22:15
  • Nice link, I do recall having seen that article before, but wasn't skilled enough to take much from it back then. Cheers. – Lee Hambley Sep 28 '12 at 07:18