Or have I missed something obvious.

I would rather the model class DID tell you which bits of plugins it was using which change the behaviour of the standard api.

But in the case of gems and plugins, alias_method_chain is exactly what you would want to use to sprinkle additional functionality on top of standard Rails methods without forcing users to adopt a different API. A good example of this is will_paginate, which allows users to call paginate() on standard AR::Base collections without modifying their models to inherit from something like WillPaginate::PaginatedRecord.

But then I found something. The excellent Ruby Facets library introduces a method called ‘Kernel#as’ (description: “Returns a As-functor that allows one to call any ancestor‘s method directly of the given object.”)

So I now have a method in the form builder called ‘original’, which is simply:

def original; return self.as(ancestor); end

So the form can choose to have the customizations provided by my form builder if it wants, by simply using text_field, or it can do this if I have a unique requirement that I don’t want to hack into the form builder (because it’s only going to be used once):

Another reason to use alias_method instead of super gone!

Note on usage: ‘form.original.send(:text_field, …)’ doesn’t work. Kernel#as can’t be used like this, you have to use Kernel#send_as

def find(*args)
  options = args.last.is_a?(Hash) ? args.last : {}
  unless options.delete(:skip_my_new_feature)
    # perform new feature
  end
  super
end

This effectively provides a flag to turn off the new feature through the existing API. This sort of API is already in use by Rails (via a_m_c) in AR::Base#save, and it works better than trying to access an incidental byproduct of a_m_c.

But honestly, if you wanted the original around, you should probably alias it off to the side for continued use, and then redefine the original method and use super.

def original_find
self.superclass.find
end

Is that the way then ?