Replace 'function_exists' with 'is_callable'

Feature requests need to go against the current development version in Drupal 7.

Under what circumstances would we want to use a method or static method for a menu or form callback? If we do, shouldn't that be integrated into the menu/form structure more cleanly?

+1 for this change - I recall having to write a silly wrapper function in a similar situation before.

A form submit handler can have a static variable quite easily, and store data in its own static non-global object. To wit:

class MyClass {
  protected $persistentStuff;
  function process($form_id, $form_state) {
    // Do stuff
  }
}

function example_form_submit($form_id, $form_state) {
  static $data;

  if (empty($data)) {
    $data = new MyClass();
  }

  return $data->process($form_id, $form_state);
}

Factory functions are *really* easy in PHP. I'm still not convinced of the need here. Besides, the Registry patch will be changing the way that works anyway. :-)

@stashlbai: The question for me that has still not been answered is "er, why?" Any patch or feature request needs to be able to answer that question, which is sometimes easy and sometimes difficult. In this case, I still don't understand "er, why?" (And I say that as a strong proponent of leveraging more OOP in Drupal 7 where it makes sense to do so; I'm just not convinced that this "makes sense to do so".)

As for namespaces in PHP 5.3, that's not on our radar for a while yet. :-) Besides, the current implementation is rather function-unfriendly, IMO. Static methods and namespaced functions look identical, and the response on php-internals when that was raised was "who the heck uses both classes and functions and would need namespaces?" Of course, I do, but they don't listen to me. :-)

Patch no longer applies.

D8 material, where hopefully, we'll usher in much more OOP support where it makes sense to do so.

Bump! We are now on PHP 5.3 and this is a must. instead of writing one-liner process - ajax wrapper - whatnot functions and putting their names in we could put in the function itself. WIN.

Not critical. Nothing breaks horribly if this isn't done, as evidenced by Drupals 1, 2, 3...

Note that there are several patches in the queue that remove function_exists() checks where they cause things to silently fail.

#1059884: Drop function_exists for 'callback' functions is one. Let's try to consider that as well as/instead of writing a huge find and replace patch. This isn't an argument against using is_callable() at all.

The existing patch is for Drupal 5, clearly not even close to usable at this point. Repeating Crell in #9, this issue is not adequately explained. If there is a demonstrable benefit or reason, this can be bumped. As is, our new policy at http://drupal.org/node/1201874 causes issues like this one to prevent new feature development if it's categorized as major.

Closing after lack of activity.