call_user_func('a_callback_function');
call_user_func(array('AClass', 'aCallback'));
call_user_func(array($obj, 'aCallback'));
$callback = 'a_callback_function';
$callback();
$callback = array($obj, 'aCallback');
$callback();
What can we use this for? The most obvious and straight forward this is a lightweight state pattern implementation -
$a_thing()
Will behave differently depending on the value of the $a_thing variable, it's state. Another way to look at php callbacks is as proxies for 'real' functions, class or object methods.
Oh, let's not forget is_callable, it's a very useful little number.
The facility of PHP objects to encapsulate a state and us being able to access this state later can be used to turn them into functions. Let's consider:
class aClass{
var $state;
function get() { return $state; }
function next() { $state=random; }
function callbacks() { return array( array($this,'get'), array($this, 'next'));}
}
$obj = new aClass();
list( $random, $next_random ) = $obj->callbacks();
echo $random();
echo $next_random();
I decided to split the relations api from the more advanced issues realted to the current sqlgen implementation. The main reason for this split is due to the never ending discussions about what is a relation on drupal forums, irc, mailing lists, etc...
The relations api is going to be a simple implementation of a tree and graph indexes, with emebeded SQL. You should be able to do things like - get related nodes; get next, previous, parent, children, sibling nodes.
Long term-wise we should be able to replace the book and taxonomy implementations of the database using this api. I'm intentionally going to make it extremely minimalistic, since I'm really not a supporter of using embdedded sql statements.