Callable typehint View as Markdown

How is this argument different than the one in favor of type hinting (or
whatever was what ended in trunk)?

On 7 Jun 2011 00:16, "Matthew Weier O'Phinney" weierophinney@php.net
wrote:

Like I mentioned in the other thread (which I probably should had
repeated here), a lot of libs/frameworks are using the 'Closure'
typehint for callbacks.

Well, they are wrong (unless they mean to use only closures and not
callbacks). But that's no reason to do wrong thing in the language
too.

The problem with that is a function name as a string and
array("classname", "functionname") are considered is_callable(). To
get through the intentions of the Closure hint, I would have to wrap
the actual callback in a closure - which doesn't make any sense.

"callable" is not actually even a type. If we make it a language
construct, then why 'authenticated DB connection', 'name of readable
file', 'valid stream URL', 'validated XML', 'string in UTF-8 no longer
than 255 characters' or 'balanced binary tree' is not a language
construct? I don't think we need to put every data check into the
language, especially that it actually makes it worse - you can
gracefully handle user-space check, but not a strict typing error.

The point, though, is that with such a typehint available, we can reduce
boilerplate code like the following:

public function addCallback($callback)
{
if (!is_callback($callback)) {
throw new InvalidArgumentException();
}

The typehint makes this simpler:

public function addCallback(callback $callback)

which allows us to rely on PHP's native error handling. I, for one,
would love to see this.

--
Matthew Weier O'Phinney
Project Lead | matthew@zend.com
Zend Framework | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc

Hi!

> The point, though, is that with such a typehint available, we can reduce
> boilerplate code like the following:

Sure. How about reducing boilterplate code like this:

if(is_readable($foo)) {
$var = file_get_contents($foo);
} else {
throw InvalidArgumentException();
}

Why won't we make language construct to do that too? I don't think these
things belong in the language syntax.

>
> public function addCallback($callback)
> {
> if (!is_callback($callback)) {
> throw new InvalidArgumentException();
> }
>
> The typehint makes this simpler:
>
> public function addCallback(callback $callback)
>

You understand that these two pieces of code are completely different -
for one, you can't catch failing strict type check upstream of
addCallback and recover.

> which allows us to rely on PHP's native error handling. I, for one,
> would love to see this.

I wouldn't love it a bit, frankly, as "rely on PHP's native error
handling" in this context means "bombing out in runtime without any idea
what went wrong". When you have exception, you could make it print what
happened and recover, if you want. When you have fatal error, you can't
do much at all.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

The point, though, is that with such a typehint available, we can
reduce boilerplate code like the following:

public function addCallback($callback)
{
    if (!is_callback($callback)) {
        throw new InvalidArgumentException();
    }

The typehint makes this simpler:

public function addCallback(callback $callback)

which allows us to rely on PHP's native error handling. I, for one,
would love to see this.

That's the same reason why I wanted scalar type hints....

cheers,
Derick

--
http://derickrethans.nl | http://xdebug.org
Like Xdebug? Consider a donation: http://xdebug.org/donate.php
twitter: @derickr and @xdebug

Hi!

https://wiki.php.net/rfc/callable

Note also that this pseudo-type is called "callback" in all of our documentation, which means we have now documentation that says:

bool array_walk ( array &$array , callback $funcname [, mixed $userdata ] )

and type check that says "callable".

Oh, good point. It should be "callback" then, too, maybe? Or the documentation should be adjusted (which might be a good idea, as "$funcname" doesn't reflect the realities anymore).

David

For me personally it makes zero sense that having just removed strict typing
we are introducing it back through back door, but if everybody likes it so
be it.

It's strict typing to have a type-hint that can be matched by 4
different constructs (string function names, arrays, closures,
invokable classes)? Basically anything that would succeed in
call_user_func would be allowed to pass...? There's no "dynamic
typing" that I'm aware of that this would prevent. Either it's
callable, or it's not. No casting or silent type conversion is going
to change that.

So it's not making typing stricter at all. All it does is allow you
to say "I want this parameter to be able to be directly called".
What form of call you give it doesn't matter one bit. So in a
sense, it's like having a String type-hint that casts if it can, but
throws an error if it can't (Ex: an object without __toString). This
will allow if there's a way to call it, and throw an error if not.

I'm all for this addition. +1

Hi!

https://wiki.php.net/rfc/callable

It is good there's an RFC. However it seems to lack code examples. I
understand it may be obvious to the proposers how it looks like, but it'd be
nice to have the actual example there as it is done nearly everywhere else.

The patch introduces new zval type IS_CALLABLE but zval functions weren't
updated for it - IIRC at least dtor may end up being called on IS_CALLABLE
value produced in the parser.

Note also that this pseudo-type is called "callback" in all of our
documentation, which means we have now documentation that says:

bool array_walk ( array &$array , callback $funcname [, mixed $userdata ] )

and type check that says "callable".

Also, it is not clear what would happen if this type check is made against
method which is not accessible (e.g. private out of scope). Would it say
that the argument is invalid (which would be really confusing since it'd say
something like "callable expected, array given" which it technically correct
but doesn't explain why this array is not callable) or would allow it? If
not, then zend_is_callable error information should be used and displayed.
And the tests need to cover these cases, along with __call and __callStatic.

For me personally it makes zero sense that having just removed strict typing
we are introducing it back through back door, but if everybody likes it so
be it.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

hi Stas,

I have to say that we should apply our upcoming voting rule here as well.

If we don't, pls count -1 from here anyway.

Cheers,

Hi!

https://wiki.php.net/rfc/callable

It is good there's an RFC. However it seems to lack code examples. I
understand it may be obvious to the proposers how it looks like, but it'd be
nice to have the actual example there as it is done nearly everywhere else.

The patch introduces new zval type IS_CALLABLE but zval functions weren't
updated for it - IIRC at least dtor may end up being called on IS_CALLABLE
value produced in the parser.

Note also that this pseudo-type is called "callback" in all of our
documentation, which means we have now documentation that says:

bool array_walk ( array &$array , callback $funcname [, mixed $userdata ] )

and type check that says "callable".

Also, it is not clear what would happen if this type check is made against
method which is not accessible (e.g. private out of scope). Would it say
that the argument is invalid (which would be really confusing since it'd say
something like "callable expected, array given" which it technically correct
but doesn't explain why this array is not callable) or would allow it? If
not, then zend_is_callable error information should be used and displayed.
And the tests need to cover these cases, along with __call and __callStatic.

For me personally it makes zero sense that having just removed strict typing
we are introducing it back through back door, but if everybody likes it so
be it.

Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227

--

--
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Hi!

https://wiki.php.net/rfc/callable

It is good there's an RFC. However it seems to lack code examples. I
understand it may be obvious to the proposers how it looks like, but
it'd be nice to have the actual example there as it is done nearly
everywhere else.

The RFC is missing information about what happens in codebases which
already have a "callable" type declared. Will that be prevented or will
they hit a runtime error? ("callable expected, callable type found")

What about default values? Will
function foo(callback $cb = 'strpos') { }
be valid?

The information on reflection is limited. what shall
Reflection::Parameter::getTypehint() return? Will that method allow to
differ between a class type and this "magic"?

What about ARGINFO? Will internal functions be able to define this type
via ARGINFO? How will this be reported in php --rf function?

johannes

function foo(callable $cb) {
    $cb();
}
foo("strpos"); // This one in fact is illegal but won't be prevented

<snip> sorry for resurrecting the thread, but I think that having a Callable typehint would be nice, and I agree with Etienne that the generic arguments against typehints doesn't really apply here.

We've had "callable" since 5.4.0.

--
Ferenc Kovács
@Tyr43l - http://tyrael.hu