Class.subclasses vs. ActiveRecord::Base.subclasses, curiosity or bug?

rubyonrails-core
1

I ran into an interesting curiosity today when a whole bunch of our tests started breaking mysteriously, with various strings getting messages they didn’t understand.

Non-Rails prolog

What triggered it was the fact that in my branch I was weaning the app from using Facets. Before my time, various facet’s methods got used a lot, but over time the usage has been greatly reduced, and we are using a back level version of the gem to-boot. I started working with a new co-worker the other day, and when we set up her new machine, we discovered, that the old gem doesn’t seem to be available anymore. So we patched around the problem in environment.rb to only load the one file we THOUGHT we needed.

However, what I discovered is that we were using an implementation of Class.subclasses from facets which returns an array of the descendant classes of a class. Now that that wasn’t there anymore, subclasses was returning an array of class names rather than the actual classes, hence the problem.

At first I was a bit confused, since I found that ActiveRecord::Base defines a class method subclasses and it DOES return an array of class objects. When I ran the test under the debugger, and stepped into the call of self.subclasses, I discovered that I’d been mistakenly thinking that the object in question was an AR model, when in fact it was just a subclass of Object, something I realized when the debugger showed that I was in an ActiveSupport extension of Class, which defines a subclasses method which returns an array of method names.

So to the point.

Why are AS and AR defining this method separately? I suspect that the AS code is there to support class reloading during development since the method is in lib/active_support/core_ext/class/removal.rb, and the AR method is there to support STI and related stuff. On the surface it would seem that there are one or more potential bugs lurking here, but I’m not sure, so I thought I’d ask those wiser in the arcana of Rails history.

2

Your suspicion is spot-on -- they were born and then evolved for different reasons.

You could consider AR::Base.subclasses a specialization because it doesn't have to walk ObjectSpace to find all subclasses; it remembers using the inherited hook (faster).

In production mode, it would be a waste to track all subclasses of all classes so we don't want AR's implementation to replace Active Support's. But in AR we always need the list regardless of environment, so the other implementation is more sensible.

Looking at the AR code, though.. it could use some cleanup + speedup.

Best, jeremy

3

The annoying thing is not the difference in implementation but the difference in semantics, one gives an array of subclass names (in string form) while the other gives an array of Class objects.

4

+1 on standardizing around returning class objects. Perhaps a subclass_names method is sensible for the string form?

5

Definitely. Let's clean that up!

That is to say, please do investigate :slight_smile:

jeremy