On Fri, Aug 29, 2008 at 4:29 PM, Rick DeNatale <[EMAIL PROTECTED]> wrote: > 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.
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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
