Question: I have a table of statuses, each of which have a name attribute. Currently I can do:

```
FooStatus.find_by_name("bar")

```

And that's fine. But I'm wondering if I could do:

```
FooStatus.bar

```

So I have this approach:

```
class FooStatus < ActiveRecord::Base
  def self.method_missing(meth, *args, &block)
    if self.allowed_statuses.include?(meth.to_s.titleize)
      self.where("name = ?", meth.to_s.titleize).first
    else
      super(meth, *args, &block)
    end
  end

  def self.allowed_statuses
    self.pluck(:name)
  end
end

```

The above code works, but it leads to the following weird behavior:

```
FooStatus.respond_to?(:bar) => false
FooStatus.bar => #<FooStatus name: 'bar'>

```

That's not great, but if I try to implement respond\_to?, I get a recursion problem

```
class FooStatus < ActiveRecord::Base
  def self.method_missing(meth, *args, &block)
    if self.allowed_statuses.include?(meth.to_s.titleize)
      self.where("name = ?", meth.to_s.titleize).first
    else
      super(meth, *args, &block)
    end
  end

  def self.allowed_statuses
    self.pluck(:name)
  end

  def self.respond_to?(meth, include_private = false)
    if self.allowed_statuses.include?(meth.to_s.titleize)
      true
    else
      super(meth)
    end
  end
end

```

And that gets me:

```
FooStatus.bar => ThreadError: deadlock; recursive locking

```

Any ideas on getting method\_missing and respond\_to to work together?

Answer: 
I agree with Philip Hallstrom's suggestion. If you know allowed\_statuses when the class is built, then just loop through the list and define the methods explicitly:

```
%w(foo bar baz).each do |status|
  define_singleton_method(status) do
    where("name = ?", status.titleize).first
  end
end

```

…or if you need that list of statuses elsewhere in the code:

```
ALLOWED_STATUSES = %w(foo bar baz).freeze
ALLOWED_STATUSES.each do |status|
  define_singleton_method(status) do
    where("name = ?", status.titleize).first
  end
end

```

Clearer, shorter, and far less prone to future breakage and weird rabbit hole conflicts with ActiveRecord like the one you're in.

You can do really cool things with method\_missing and friends, but it's not the first approach to go to when doing metaprogramming. Explicit is usually better when possible.

I also agree with Philip's concernt about creating conflicts with built-in methods. Having a hard-coded list of statuses prevents that from going too far, but you might consider a convention like `FooStatus.named_bar` instead of `FooStatus.bar` if that list is likely to grow or change.
Use a scope.

```
class FooStatus < ActiveRecord::Base
  scope :bar, where(:name => "bar")

  # etc
end

```

Now, you can do `FooStatus.bar` which will return an ActiveRelation object. If you expect this to return a single instance, you could do `FooStatus.bar.first` or if many `FooStatus.bar.all`, or you could put the `.first` or `.all` on the end of the scope in which case it'll return the same thing as the finder.

You can also define a scope with a lambda if the input isn't constant (not always "bar"). [Section 13.1 of this guide has an example](http://guides.rubyonrails.org/active_record_querying.html#scopes)