Sì, c'è ... anche se si tratta di un orribile, orribile trucco:
$foo = new Foo();
function makeCallable($instance, $method)
{
return function() use ($instance, $method) {
return $instance->{$method}();//use func_get_args + call_user_func_array to support arguments
};
}
quindi è possibile utilizzare:
$callable = makeCallable($foo, 'bar');
var_dump(is_array($callable));//false
Lo svantaggio è che:
var_dump($callbale instanceof Closure);//true
Fondamentalmente, non prestare attenzione al fatto che il tuo callable è anche un array, e basta usare il suggerimento del tipo nel tuo codice base:
function foobar(callable $action)
{
return call_user_func($action);
}
Questo dovrebbe funzionare bene.
Sul motivo per cui ritieni che l'attuale serie callable sia un aspetto negativo: capisco perché ritieni che questa non sia una buona cosa. Non c'è davvero bisogno per nessuno di sapere che un particolare costrutto chiamabile è un array, una stringa o una funzione anonima (che in realtà è un'istanza della classe Closure
- un altro dettaglio di implementazione che potresti non voler passare in giro). Ma è esattamente perché i costrutti callable si presentano in molte forme, esiste il suggerimento tipo callable
: il codice che scrivi che richiede un callable non deve preoccuparsi di come viene implementata quell'entità chiamabile, basta sapere che può chiamare quel pezzo di informazioni:
function handleEvent(callable $action, array $args = null)
{
if ($args) {
return call_user_func_array($action, $args);
}
return call_user_fun($action);
}
non c'è bisogno di me per controllare se $action
è una stringa (come 'strtolower'
, un'istanza Closure
o un array) ho appena so mi può chiamare
fonte
2015-09-08 13:47:49
perché è un aspetto negativo? –
@HalayemAnis Capisco che non è un chiaro svantaggio, ma lo vedo come uno perché non mi aspetto che un callable sia un array. Sembra qualcosa di simile a un dettaglio di implementazione che non dovrebbe essere passato attorno allo – marcosh