Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:53198
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain schlueters.de from 217.114.211.66 cause and error)
To: Hannes Magnusson <hannes.magnusson@gmail.com>
Cc: Stas Malyshev <smalyshev@sugarcrm.com>, Matthew Weier O'Phinney
 <weierophinney@php.net>, internals@lists.php.net
In-Reply-To: <BANLkTimOx3xr5t50Wtjxb_HzL6ALc8gW5ghKeTJOeJD5oxQNXA@mail.gmail.com>
References: <BANLkTimU6DxovPQFP6cOXE0sKTDchx5Ltg@mail.gmail.com>
	 <4DED3D5B.6030307@oracle.com>
	 <BANLkTimEEh7eT7bH4qb9gPro_R2sKw24SyJ7JwWp8j6Ew2fH0Q@mail.gmail.com>
	 <F8.04.15404.AAD4EED4@pb1.pair.com> <4DEE782E.1020605@sugarcrm.com>
	 <1307489981.23373.31.camel@guybrush>
	 <BANLkTimOx3xr5t50Wtjxb_HzL6ALc8gW5ghKeTJOeJD5oxQNXA@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Wed, 08 Jun 2011 12:04:24 +0200
Message-ID: <1307527464.3635.395.camel@guybrush>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] Callable type
From: johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)

On Wed, 2011-06-08 at 10:38 +0200, Hannes Magnusson wrote:
> 2011/6/8 Johannes Schlüter <johannes@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