More importantly, has_finder / named_scope provides this functionality in a more flexible way, and is committed to core Rails. So please, use it instead!

class User
  has_many_with_args :whispers_from, :sender,
    :class_name => 'Whisper',
    :foreign_key => 'recipient_id',
    :conditions => 'sender_id = #{sender.id}'
end

must be

class User
  has_many_with_args :whispers_from, :sender,
    :class_name => 'Whisper',
    :foreign_key => 'recipient_id',
    :conditions => "sender_id = #{sender.id}"
end

Person.greeks { find(:all) } vs. Person.greeks.find(:all)

Scope_out doesn’t allow composition without a sep declaration, vs. w/ HasFinder it comes for free:

combined_scope :greek_and_mortal #only necessary for scope_out

Person.greek_and_mortal { find(:all) } vs. Person.greeks.mortal.find(:all)

This is compelling when you have lots of combinations of scopes.

scope_out doesn’t work like a proxy:

Person.find_greek_and_mortal.each { … } and Person.calculate_greek_and_mortal(:count, …) vs.
Person.greeks.mortals.each { … }, Person.count Person.greeks.mortals.count

The lambda form in has_finder is very useful:

Person.gendered(:male).with_hair_color(:purple).count

It works for free with has_many. With scope_out, you have to explicitly say:

class Army
  has_many :people, :extend => Person::AssociationMethods
end

With HasFinder that comes for free:

an_army.people.greeks

Finally, it supports proxy extensions a la:

has_many :foo do
  def my_custom_method
  end
end
 
has_finder :mortals, :conditions => ... do
  def my_custom_method
  end
end

hence: Person.mortals.my_custom_method

Anyway, hope you enjoy. I believe HasFinder is to be renamed NamedScope; it will be included in Rails 2.1

I worry chaining finders togethers like that could pretty easily generate queries that don’t make the best use of mysql’s indices, but nothing deliberate use wouldn’t ease.

The ability to generate these kinds of finders with the lambda syntax in has_finder looks really nice as well. I’ll have to dig through it to see some of the implementation details.
Thanks for the heads-up!

Now that I have a tag with many taggings and they all have to belongs to the same category as the current tag. How do we do this thru the has_many … :conditions?

I took the hint from this post to use single quote on the :conditions clause to delay the evaluation of the condition till executing time.

This is the original declaration for the Tag model

class Tag < ActiveRecord::Base
  has_many :taggings
end

The modified version with dynamic condition is

class Tag < ActiveRecord::Base
  has_many :taggings, :conditions => '#{Tagging.table_name}.category_id = #{self.send(:category_id)}'
end

Notice the single quote for the conditions, and I used #{self.send(:category_id)} to tell the Tag instance, at runtime, to dynamically invoke the cateogory_id attribute reader. A quick glance to check on the tail log for development.log confirmed that the query was indeed evaluated at runtime!

No more hacking just pure coding fun!

BTW: I’m running Rails 1.2.5 still.