FormHelper#fields_for has illogical (and unused) option

I've just found an option in FormHelper#fields_for that seems to be both, illogical and (therefore) unused.

In the case statement, there's the following snippet:

# ...
when Array
  object = record_or_name_or_array.last
  object_name = ActionController::RecordIdentifier.singular_class_name(object)
  apply_form_for_options!(record_or_name_or_array, options)
# ...

I was suspicious because this isn't documented and the apply_form_options! call doesn't make sense because it generates form-specific stuff like the action attribute and html options for the form itself and has nothing to do with fields_for that only generates a scope around a given entity. I think this may have been copied from form_for at the time that fields_for was introduced as a new feature.

Using it inadvertedly produces routing errors. With nested resources (e.g. product has many prices and fields_for [:product, @price]) you get insufficient parameters and without nested resources (fields_for [:product, @price]) you get unknown named routes. It only works if you specify a :url parameter (fields_for [:product, @price], :url => 'whatever') and, of course, doesn't produce any sensible output (i.e. it acts like fields_for :product).

Since the functionality doesn't make sense, I tried removing it. It didn't break any tests so I guess this wasn't only undocumented but also unused.

Why does removing it make sense, apart from the fact that this is non-existent functionality?

Firstly, it may give us slightly improved performance when passing in an actual object as its first parameter because it doesn't have one redundant check on the type of the parameter.

Secondly, it may be worth removing it for now and later re-introducing it with sensible behavior with regards to a discussion on the Core list (http://groups.google.com/group/r.... One could then pass in an array of symbols/objects and have it build a nested hash (similar to form_for building a nested route).

Patch is attached.