Why doesn't Ruby include built-in class reloading? [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 8 years ago.

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.

Answer 1

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.