HasOneThroughAssociation should not derive from HasManyThroughAssociation

I see what these two classes have in common, but I don't like that
they share implementation via an inheritance relationship,
particularly given how badly this violates Liskov substitutability.
So, I moved the shared functionality into a module and included that
module into both HasManyThroughAssociation and
HasOneThroughAssociation, as well as making HasOneThroughAssociation a
subclass of HasOneAssociation. This makes the inheritance hierarchy
more intuitive, and cleans up the code a bit, since there's now no
need for overloads of collection-specific methods in a non-collection
association class. I also eliminated an extraneous database call
caused (I believe) by the association setter forcing a reload of
HasOneThroughAssociation objects.

Ticket for this patch is at

My initial motivation for the above patch was a patch to allow
association proxies to correctly respond to methods defined by the
#method_missing method on their targets. My initial attempts were all
complicated by the fact that HasOneThroughAssociation inherited some
collection-specific jimcrackery from HasManyThroughAssociation. With
the above patch in place, the solution became much simpler.

Ticket for this second patch is at
. Two things to note about this patch: 1) it will cause a test
failure if applied without the previous patch, due to the issue
mentioned above; 2) I haven't looked in detail at potential
performance implications of using #include? rather than #respond_to?

I've also included a third patch to fix a test failure that happens
only when has_many_through_associations_test.rb is run by itself, and
some other minor cleanup refactorings. Ticket for this final patch is
at http://rails.lighthouseapp.com/projects/8994/tickets/1644-minor-refactorings-and-order-dependent-test-failure-fix

+1 for cleaning up this mess.


I pushed for this same refactoring a couple of months ago to fix some
issues with assignment to the proxies. It's overdue.