Add a drupal_build_form() helper for using a method as the callback

+++ b/core/includes/form.incundefined
@@ -138,6 +138,28 @@ function drupal_get_form($form_id) {
+ * @param callable $callback
+ *   A callback to be used for building the form.

Maybe this param should be $callable instead? Just for clarity? or maybe not, I'm not sure on that :) Atleast maybe this could reference that the parameter is the same as that of call_user_func_array?

Yeah, I guess people can look up callables if they need to.

Consistency is good. I think the patch is just fine how it is now.

This looks pretty good. Should we provide some test for that?

I dunno, we used http://api.drupal.org/api/drupal/core%21modules%21system%21system.api.ph... before for specifying callbacks...

This seems like a reasonable small cleanup. If nothing else it shortens a few code blocks elsewhere by reducing duplication.

Looks fine to me as well Committed/pushed to 8.x.

Seems reasonable to backport.

Will also need a change notice.

Hell no. Sorry for dropping the ball but step one is rolling this back and making something better.

1. drupal_get_form($this). Make an interface. Methods:
   1. formGetId. Default to get_class($this) I think.
   2. form
   3. formValidate
   4. formSubmit
2. Multiple forms per class? Should really be rare, but drupal_get_form(array($this, 'foo')). Methods:
   1. formFooGetId. Default to get_class($this) I think.
   2. formFoo
   3. formFooValidate
   4. formFooSubmit

Hm. If we were to go with chx's proposal, I'd suggest restricting it to one form per object. Multiple forms just gets messy.

Note that allowing an object there would mean some forms could not be used as declared callbacks (from menu items/routes, etc.) as those need to be static strings. That may be OK, but does create two classes of form (no pun intended).

http://drupal.org/node/1910136 is a small change notice.

I talked to Daniel and this was an x-post and I unpublished the change notice for now.