Rails core - Aug 2008 - Class.subclasses vs. ActiveRecord::Base.subclasses, curiosity or bug?

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.

-- 
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 rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

On Fri, Aug 29, 2008 at 4:29 PM, Rick DeNatale <rick.denatale@gmail.com>
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 rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

On Fri, Aug 29, 2008 at 9:43 PM, Jeremy Kemper <jeremy@bitsweat.net>
wrote:
>
> On Fri, Aug 29, 2008 at 4:29 PM, Rick DeNatale
<rick.denatale@gmail.com>
> 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 rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

+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
<rick.denatale@gmail.com>wrote:
> On Fri, Aug 29, 2008 at 9:43 PM, Jeremy Kemper
<jeremy@bitsweat.net>wrote:
>
>>
>> On Fri, Aug 29, 2008 at 4:29 PM, Rick DeNatale
<rick.denatale@gmail.com>
>> 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 rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---

Definitely. Let''s clean that up!

That is to say, please do investigate :)

jeremy

On Thu, Sep 4, 2008 at 8:15 PM, Blake Watters <blake@near-time.com>
wrote:
> +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
<rick.denatale@gmail.com>
> wrote:
>>
>> On Fri, Aug 29, 2008 at 9:43 PM, Jeremy Kemper
<jeremy@bitsweat.net>
>> wrote:
>>>
>>> On Fri, Aug 29, 2008 at 4:29 PM, Rick DeNatale
<rick.denatale@gmail.com>
>>> 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 rubyonrails-core@googlegroups.com
To unsubscribe from this group, send email to
rubyonrails-core+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en
-~----------~----~----~----~------~----~------~--~---