do -> does

Are you sure you are running 5.4? Your your test script:

% php53 test.php

Catchable fatal error: Argument 1 passed to test() must be an instance of 
callable, array given, called in /home/rasmus/r on line 6 and defined in 
/home/rasmus/r on line 2

% php54 test.php

Catchable fatal error: Argument 1 passed to test() must be callable, array 
given, called in /home/rasmus/r on line 6 and defined in /home/rasmus/r on line 
2

Sorry, in PHP 5.4 there is not "an instance of" in error message. But that's not the point.

Possible fix is to change in file zend_execute.c on line 645 flag IS_CALLABLE_CHECK_SILENT to IS_CALLABLE_CHECK_SYNTAX_ONLY.

But it only triggers the autoloader when you pass it something that looks exactly 
like A::b(). In this case it will go try to load 'A' in order to see if there is 
a b() method. If you pass it array(1,2,3) it will obviously not trigger the 
autoloader so I think your assertion that this will cause "major performance 
issues" is a bit drastic.

I understand its behavior, but I think it is wrong. Callable shouldn't check the existence of class, but only check argument is a syntactically correct. Otherwise it makes lazy-loading impossible. Not every callback is called. 

In addition, the non-existence of class results in confusing error message: "must be callable, string given". So "A::b" is not callable?

Well, that's a very subjective thing. callable matches the default behaviour of 
is_callable(). In most cases when you pass a callable it is going to get called. 
If you want to implement lazy loading it is simple enough to do an is_callable 
syntax-check only in your method itself. The default had to be set to one or the 
other and we tend to set things to the common use case.

Rasmus we're talking about two different things:

1) Error message "Must be callable, string given" means, that something other than string was expected. Do you agree? I think current message is confusing.

2) The behavior of typehint is subjective, of course. But it would be nice if you could consider, if it is really correct. We are talking about "type hint" - and checking of validity of a *type*. 

Type hint "array" means that the argument must be array. It's just about the type. Validity of array must be checked by function itself. The type hint "callable" I expect checks if argument is valid callable type (valid syntax), nothing more.

1) Yes, something other than a string was expected. When a string points to 
something that isn't a callable function, then it is just a string, so I 
consider the message correct.

2) Yes, I consider it correct. A callable isn't a basic type like a string. It 
has to have a couple of characteristics, one of which is being actually callable 
which you can't know unless you check. This is what most users expect when they 
check if something is callable. If something just looks like a callable function 
and it isn't, then you end up with an uncatchable fatal when you try to call it, 
so knowing that something looks like it might be a callable function isn't very 
useful to most. They want to write robust code and catch any errors and that can 
only be done if we check for the existence of the callable function which is why 
it is the default.

And your example with array just reinforces this. An array typehint fully checks 
if an array is an array because it is a simple type that has no other 
characteristics. An array can't pass the array typehint and then fatal out when 
you try to use it as an array.

There is no logic to check is_callable by typehint - these typehint is useless, brings no new functionality. The only one possibile benefit is just check validity of the callback structure, not the callabality self.

> A callable isn't a basic type like a string.
So, this typehint behaves differently than others. Yeah, so you prefer to mix things together and make php much more chaotic.
> This is what most users expect when they check if something is callable.
Some research available? Or just empty words?

From my point of view php is heading to hell by making these type of shortcuts. Yes, we are lazy programmers, but there is no need to rewrite if (is_callable(..)) as a typehint.

1) "Yes, something other than a string was expected." Really? What exactly is expected? When a string points to something that _is_ callable, then it is not a string? 

call_user_func('xxx') triggers error 'expects parameter 1 to be a valid callback, function 'xxx' not found or invalid function name' which is perfectly understandable. Why the same function with typehint callable will not trigger the same error message? It will trigger 'Argument 1 passed to call_user_funct() must be callable, string given', which says that I shouldn't use the string. And that's not simply true.

2) I would totally agree with you, if PHP was static language. But PHP is dynamic language and it makes sense to have stored in the variable name of class/function that has not yet been loaded. And most importantly: the life cycle of PHP is a single HTTP request, lazy loading is very important for good performance.

Hmm... I agree with David Grudl that current behavior is not ideal... so what 
about two typehints? callback and callable?

function testA(callback $a)
{
//callback checks only syntax
}

function testB(callable $a)
{
//callable checks if it is really callable
}

I agree with paladin, but I don't think that *callable* is useful.

@paladin / @honza: We certainly won't introduce another type hint just to cover some minority use case. Type hints are there to simplify the most common type checks and callability-without-actual-callability is certainly not one of the common cases. If you have special needs you can always just do the manual is_callable call.

@nikic I don't think that the use case presented here a minority one. Callbacks 
are often send as arguments. The current typehint functionality is completely 
useless.

Here's the use case.

I have read the http://php.net/manual/en/language.types.callable.php and know several syntax variants of specifying callable instances. Among them the array and string ones.

I want to make higher-order function definition accepting a callable instance.
To both enforce the argument type and provide a type hint for other developers I make the following definition:

private function wrapper(callable $procedure) {
  // pre-actions
  $procedure();
  // post-actions
}

Next developer creates new method in the same class, and inside it wraps some other method of the same class:

$this->wrapper([$this, 'someOtherMethod']);

PHP responds with parse error described by OP, and that developer is forced to use anonymous function instead.

$this->wrapper(function () { $this->someOtherMethod(); });

This can be considered a minor annoyance, but it's explicitly stated in the documentation that we can specify callable instances by arrays, and [$this, 'someOtherMethod'] *is* callable, because, let's say, 'someOtherMethod' actually exists in this class.

All your previous discussion is meaningless, because the core of the problem is this: docs say that you can specify callables as array (and you actually can) but `callable` type hint DOES NOT ACCEPT ARRAYS.

Honestly, I don't care whether `callable` type hint checks actual callability or not, but I as a programer assume that `callable` must accept anything `call_user_func` accepts, with same behavior. Fatal error is completely unjustified here.