On Wed, 2011-06-08 at 10:38 +0200, Hannes Magnusson wrote:
> 2011/6/8 Johannes Schlüter <johan...@schlueters.de>:
> > On Tue, 2011-06-07 at 12:12 -0700, Stas Malyshev wrote:
> >> 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")
>
> You mean an interface/class with that name?
> The error would be 'expected instanceof callable, string/array/closure
> recieved.
>
> gettype("strpos") will still return a string, not callable.
>
> A callable wouldn't be fully featured type.
Which means that
class callable { }
function f(callable $c) { }
f(new callable);
will be allowed by the parser but have a "strange" result? (This isn't
the case w/ array type hints as array is a parser token and can't be
used as class name (from userland at least))
If this feature is accepted we should have a good behavior there. I'm
not sure whether the right solution is to disallow naming classes
"callable" (or "callback" or whatever the name will be in the end)
Funny thing: Google Codesearch gives me one application defining an
class Callable. In that specific case the above thing would work:
http://google.com/codesearch/p?hl=en#vA7-IQSCKhE/trunk/php/framework/project/App/util/Callable.php&q=lang:php%20%22class%20callable%22&sa=N&cd=9&ct=rc
Sidenote: Looking for "class callback" gives me more false positives,
but also a few places where that classname is being used:
http://google.com/codesearch/p?hl=en#lYWaFFstwm4/tests/cases/libs/model/models.php&q=lang:php%20%22class%20callback%22&sa=N&cd=11&ct=rc
http://google.com/codesearch/p?hl=en#PbKZfG2CZcc/trunk/phpQuery/phpQuery/Callback.php&q=lang:php%20%22class%20callback%22&sa=N&cd=12&ct=rc&l=29
http://google.com/codesearch/p?hl=en#f6tUYQTbHns/trunk/framework/activerecord/lib/CallBack.php&q=lang:php%20%22class%20callback%22&sa=N&cd=21&ct=rc
...
> > What about default values? Will
> > function foo(callback $cb = 'strpos') { }
> > be valid?
>
> No default values, other then NULL allowed.
> Otherwise we would need to support array("classname", "methodname")
> too, and then people would want default array values for array
> typehinting etc etc etc.
Ok. I assume NULL as default value would be allowed, though. This would
be consistent for the language and allow such things:
function foo(callback $cb = NULL) {
if (!$cb) {
$cb = function() { /* .. default implementation */
}
....
}
> > 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"?
>
> There is no such method anymore :)
Good point. While I'd see that as defect, independently from scalar and
other type hints ;-)
> > What about ARGINFO? Will internal functions be able to define this type
> > via ARGINFO? How will this be reported in `php --rf function`?
>
> I didn't include arginfo in the patch, but good point. It should
> probably be included.
> As Felipe pointed out, ext/reflection hasn't been updated.
> It should return [ callable $foobar ], just like with any other typehint
That is fine.
Having the behavior cleared I wonder how useful it is in practical
terms. A class type hint guarantees me I can do a specific call to
methods defined in the class/interface. The proposed type hint tells me
I can call it in some way. It won't ensure that the signature is
compatible with what I expect.
function foo(callable $cb) {
$cb();
}
foo("strpos"); // This one in fact is illegal but won't be prevented
But maybe this doesn't matter as type hints purely serve documentation
(as E_RECOVERABLE are useless unless we make them Exceptions ...) while
even for documentation purpose more information is needed.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
