call_user_func_array syntax

[GoogleCodeExporter]

We need to update our calling syntax for this function.  This is general across 
all views.  For a good example, look at the built-in known_members mod.

What version of the board are you using? e.g. 3.2.3 or 4.0 revision
4b53033f8a1b.
4

What version of PHP and MySQL does the board run on?
PHP 5.1.6

Please provide any additional information below.

In the known_members mod, we do this:

init:
event::register('corpDetail_assembling', 'known_members::addView');

class known_members
{
public static function addView($home) { 
$home->addView('known_members',"known_members::view");}
public static function view($home) {...}
}

Then calling it in corp_detail.php thus:
if(isset($this->viewList[$this->view])) {
 return call_user_func_array($this->viewList[$this->view], array(&$this));
}

That calling syntax is not correct, at least for my version of PHP.  It wants 
the class/method as components of an array thus:

return call_user_func_array(array('known_members','view'), array(&$this));

I don't know if we want to change the way we register statics, or write a 
call_user_func_array wrapper that decomposes the class::member string into an 
array.

Original issue reported on code.google.com by jjl...@gmail.com on 16 Dec 2011 at 3:24

[GoogleCodeExporter]

Revision e219281b0f19 fixed the known members mod. Setting a view should be 
done by:
addView($home) { 
$home->addView(array('known_members','view'),"known_members::view");}

event::register still accepts both ways, converting internally. I updated the 
documentation to make it clearer that array(class, method) is preferred. 
Accepting both seems confusing but we can break that in a future release. :)

Original comment by kovellia on 17 Dec 2011 at 3:07

• Changed state: Fixed

[GoogleCodeExporter]

Isn't the core problem that:

1. class::static_member sometimes works
2. array( 'class', 'static_member' ) always works
and
3. array( 'class', 'instance_member' ) always works

?

Shouldn't you just disable the static syntax, perhaps just deconstructing it 
inside of addView?

function addView( $wang, $chung ) { // psuedocode
  $array_out = $wang;
  if ( preg_match( '/::/', $wang  ) > 0 ) {
    $array_out = preg_split( '/::/', $wang )
  }
  call_user_fun_array( $array_out, $chung );
}

v0v  mountains and molehills.  I'm just going to move on.

Original comment by jjl...@gmail.com on 19 Dec 2011 at 1:54

[GoogleCodeExporter]

Working around all the various ways PHP will let you run code leads to madness. 
You are quite right that that would work, but when you add code to allow for 
all the various combinations possible, things get unwieldy and hard to follow. 
My hope is that by changing the demonstration code in known members, people 
will follow either the demo code, or the php documentation, either of which 
will give the 'correct' approach. (This may also lead to madness but it's a 
monsters under the bed sort rather than a Cthulhu shaking you awake madness.)

I may be biased, having just read the involved party code for doing things like 
adding alliances to a killlist. It takes an integer, an array of integers, an 
object with a getID() method, or an array of such objects. It works just fine, 
but the code overall would be easier to follow if there was only one method, or 
at most if it allowed either integer or array of integers.

I add in tangled mess of exceptions when I have to, but I'm hoping I don't have 
to here. We've gone a few years without problems so hope is viable.

Original comment by kovellia on 19 Dec 2011 at 2:13