+1 on standardizing around returning class objects. Perhaps a subclass_names method is sensible for the string form?
On Thu, Sep 4, 2008 at 1:57 PM, Rick DeNatale <[EMAIL PROTECTED]>wrote: > On Fri, Aug 29, 2008 at 9:43 PM, Jeremy Kemper <[EMAIL PROTECTED]>wrote: > >> >> 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 >> > > 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. > -- > Rick DeNatale > > My blog on Ruby > http://talklikeaduck.denhaven2.com/ > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
