# Callable typehint - Thread: https://externals.io/message/53074 - Original archive: https://news-web.php.net/php.internals/53074 - Started by Hannes Magnusson on 2011-06-06T19:41:23+00:00 - Messages: 63 - Page 1 of 3: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/53074.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #53074 — Hannes Magnusson — 2011-06-06T19:41:23+00:00 URL: https://externals.io/message/53074#53074 Hi As quickly mentioned in the '$arr = array('Hello', 'world'); $arr();' thread[1], we are hitting the need for a callable typehint. See attached patch+phpt; Any objections to include it in 5.4? -Hannes [1] http://php.markmail.org/message/gdas65h3im52sleg --- ## #53077 — Stas Malyshev — 2011-06-06T20:35:53+00:00 URL: https://externals.io/message/53074#53077 · In reply to: #53074 Hi! > See attached patch+phpt; Any objections to include it in 5.4? Yes, same objections as for other static typing. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #53079 — Hannes Magnusson — 2011-06-06T20:48:59+00:00 URL: https://externals.io/message/53074#53079 · In reply to: #53077 > Hi! > > > […] > > Yes, same objections as for other static typing. > That was totally not the purpose of this, and I don't quite understand how you made the connection. 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. 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. -Hannes --- ## #53080 — Christopher Jones — 2011-06-06T20:49:31+00:00 URL: https://externals.io/message/53074#53080 · In reply to: #53074 > See attached patch+phpt; Any objections to include it in 5.4? Hannes, How about putting up an RFC for it? Even a brief RFC would be better than none. Chris -- Email: christopher.jones@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ --- ## #53082 — Stas Malyshev — 2011-06-06T21:17:08+00:00 URL: https://externals.io/message/53074#53082 · In reply to: #53079 Hi! > 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. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #53088 — Matthew Weier O'Phinney — 2011-06-06T22:16:18+00:00 URL: https://externals.io/message/53074#53088 · In reply to: #53082 > > […] > > 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. > > > […] > > "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 --- ## #53090 — Pierre Joye — 2011-06-06T22:26:56+00:00 URL: https://externals.io/message/53074#53090 · In reply to: #53088 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" wrote: > > > […] > > 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 --- ## #53091 — Matthew Weier O'Phinney — 2011-06-06T22:33:08+00:00 URL: https://externals.io/message/53074#53091 · In reply to: #53090 > --0016e6de0029ddc06f04a5129914 > Content-Type: text/plain; charset=ISO-8859-1 > > How is this argument different than the one in favor of type hinting (or > whatever was what ended in trunk)? I was simply voicing my support for Hannes' patch, and trying to clarify my understanding of it for Stas. If you're comparing it to the scalar typehinting patch, I think it's a far cry from that -- this is about providing a unified typehint for functionality represented over multiple constructs in PHP, in order to reduce code in applications. If it offers no BC issues, and allows developers to simplify code and remove boilerplate (which can easily introduce new errors on each iteration), then why wouldn't it be a good idea? > On 7 Jun 2011 00:16, "Matthew Weier O'Phinney" > wrote: > > […] > > --0016e6de0029ddc06f04a5129914-- -- 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 --- ## #53092 — Etienne Kneuss — 2011-06-06T22:41:36+00:00 URL: https://externals.io/message/53074#53092 · In reply to: #53077 Hi, > Hi! > > > […] > > Yes, same objections as for other static typing. Those objections do not apply here IMO. IIRC, the main objections were that if we introduce strict hints for scalar values, then we start rejecting stuff that would "just work" via implicit conversions before. i.e. "2" vs 2. In this case, if you don't provide a valid callback to a function expecting a valid callback, there is no way it will "just work". Just like with other type hints, if you write function foo(A $b) and pass B which is not a subtype of A, there is no way foo() will "just work", as there is no way it will be able to interpret the value, an object of type B, as an object of type A. +1 from me, this seems very useful. > > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > > > > -- Etienne Kneuss http://www.colder.ch --- ## #53096 — Chris Stockton — 2011-06-06T22:51:45+00:00 URL: https://externals.io/message/53074#53096 · In reply to: #53074 Hello, On Mon, Jun 6, 2011 at 12:41 PM, Hannes Magnusson wrote: > Hi > > As quickly mentioned in the '$arr = array('Hello', 'world'); $arr();' > thread[1], we are hitting the need for a callable typehint. > This brings a clear and concise enhancement to PHP which I would benefit from .I have been watching our API provide more and more functions with callbacks as arguments and it would be nice to have a specific type for those to clean up the is_callable error handling. It is my opinion that comparing it to previous type hinting proposals is like comparing apples and oranges. I think it falls in align justification wise between Class Name and Array type hints. I.E. function test1(StdClass $p) .. function test2(Closure $p) ... <== doesn't this seem more justified then "Array" given the argument of previous type hinting proposals? function test3(Array $arr) +1 from me -Chris --- ## #53097 — Chris Stockton — 2011-06-06T22:52:57+00:00 URL: https://externals.io/message/53074#53097 · In reply to: #53096 Hello, On Mon, Jun 6, 2011 at 3:51 PM, Chris Stockton wrote: > Hello, > > On Mon, Jun 6, 2011 at 12:41 PM, Hannes Magnusson > wrote: > > […] > > This brings a clear and concise enhancement to PHP which I would > benefit from .I have been watching our API provide more and more > functions with callbacks as arguments and it would be nice to have a > specific type for those to clean up the is_callable error handling. > > It is my opinion that comparing it to previous type hinting proposals > is like comparing apples and oranges. I think it falls in align > justification wise between Class Name and Array type hints. > > I.E. > function test1(StdClass $p) .. > function test2(Closure $p) ... <== doesn't this seem more justified > then "Array" given the argument of previous type hinting proposals? > function test3(Array $arr) > > +1 from me > > -Chris > s/Closure/Callable/g --- ## #53103 — Ferenc Kovacs — 2011-06-06T23:01:44+00:00 URL: https://externals.io/message/53074#53103 · In reply to: #53074 On Mon, Jun 6, 2011 at 9:41 PM, Hannes Magnusson wrote: > Hi > > As quickly mentioned in the '$arr = array('Hello', 'world'); $arr();' > thread[1], we are hitting the need for a callable typehint. > > > See attached patch+phpt; Any objections to include it in 5.4? > > -Hannes > > [1] http://php.markmail.org/message/gdas65h3im52sleg > > -- > > > +1 but please create an RFC for it, or we will argue this to death. Tyrael --- ## #53105 — Stas Malyshev — 2011-06-06T23:02:15+00:00 URL: https://externals.io/message/53074#53105 · In reply to: #53088 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 --- ## #53109 — Chris Stockton — 2011-06-06T23:20:23+00:00 URL: https://externals.io/message/53074#53109 · In reply to: #53105 Hi Stas, > > 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. The patch as you probably know throws a E_RECOVERABLE_ERROR, which in my humble opinion doesn't quite fall under the end-of-world category you seem to explain there :- ) I.E. function bar($a, $b, $c, $d) { return true; } set_error_handler("bar"); class Foo { public function test(Array $arr) {} } $foo = new Foo; $foo->test('invalid'); echo "Everything will be okay.. :p"; -Chris --- ## #53110 — Derick Rethans — 2011-06-06T23:31:08+00:00 URL: https://externals.io/message/53074#53110 · In reply to: #53088 > 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 --- ## #53115 — Martin Scotta — 2011-06-07T02:50:44+00:00 URL: https://externals.io/message/53074#53115 · In reply to: #53105 Martin Scotta On Mon, Jun 6, 2011 at 8:02 PM, Stas Malyshev wrote: > Hi! > > > The point, though, is that with such a typehint available, we can reduce > > […] > > Sure. How about reducing boilterplate code like this: > > if(is_readable($foo)) { > $var = file_get_contents($foo); > } else { > throw InvalidArgumentException(); > } > trol? > > Why won't we make language construct to do that too? I don't think these > things belong in the language syntax. > > > > > […] > 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, > > […] > > 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 --- ## #53125 — Jordi Boggiano — 2011-06-07T10:09:17+00:00 URL: https://externals.io/message/53074#53125 · In reply to: #53105 > 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. The whole point is that callables are generally not constructed from user input, they're hardcoded in the code somewhere, and so if a fatal error occurs, the developer notices it, hopefully during development. With is_readable, a file can be anywhere, anytime, readable or not, it depends on the environment the code runs on, and not on the code itself, so it's not deterministic and you should therefore be able to easily handle this gracefully. Cheers -- Jordi Boggiano @seldaek :: http://seld.be/ --- ## #53142 — Hannes Magnusson — 2011-06-07T14:00:02+00:00 URL: https://externals.io/message/53074#53142 · In reply to: #53080 On Mon, Jun 6, 2011 at 22:49, Christopher Jones wrote: > > > > > > […] > > Hannes, > > How about putting up an RFC for it?  Even a brief RFC would be better than > none. > https://wiki.php.net/rfc/callable To avoid another flamewar.. Am I now supposed to create a new thread with [RFC] in the subject, wait for minimum 2 weeks, and then create a poll somewhere on the wiki and create new thread with [VOTE] in subject, and wait for another 2weeks and then if accepted by 50%+1 php.net developer, and 60% of the community votes, then I can commit? Thats the current rules of the game? -Hannes --- ## #53143 — Richard Quadling — 2011-06-07T14:04:22+00:00 URL: https://externals.io/message/53074#53143 · In reply to: #53142 > On Mon, Jun 6, 2011 at 22:49, Christopher Jones > wrote: > > […] > > https://wiki.php.net/rfc/callable > > To avoid another flamewar.. > Am I now supposed to create a new thread with [RFC] in the subject, > wait for minimum 2 weeks, and then create a poll somewhere on the wiki > and create new thread with [VOTE] in subject, and wait for another > 2weeks and then if accepted by 50%+1 php.net developer, and 60% of the > community votes, then I can commit? > Thats the current rules of the game? I always thought it was publish and be damned. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea --- ## #53144 — Hannes Magnusson — 2011-06-07T14:22:20+00:00 URL: https://externals.io/message/53074#53144 · In reply to: #53143 > > > […] > > I always thought it was publish and be damned. ;) That RFC process thread just became to much to pay attention to, so I'm unsure what the status of it is. -Hannes --- ## #53155 — Jaroslav Hanslik — 2011-06-07T15:22:54+00:00 URL: https://externals.io/message/53074#53155 · In reply to: #53074 Dne 6.6.2011 21:41, Hannes Magnusson napsal(a): > Hi > > As quickly mentioned in the '$arr = array('Hello', 'world'); $arr();' > thread[1], we are hitting the need for a callable typehint. > > > See attached patch+phpt; Any objections to include it in 5.4? > > -Hannes > > [1] http://php.markmail.org/message/gdas65h3im52sleg I like the idea. However I think the type hint should be named "callback" instead of "callable" because this name is used already in a lot of documentations and also in PHP documentation http://php.net/manual/en/language.pseudo-types.php#language.types.callback Jaroslav Hanslik --- ## #53159 — Matthew Weier O'Phinney — 2011-06-07T16:11:22+00:00 URL: https://externals.io/message/53074#53159 · In reply to: #53142 > On Mon, Jun 6, 2011 at 22:49, Christopher Jones > wrote: > > […] > > https://wiki.php.net/rfc/callable I've edited the "Problems" section to also point out that "Closure" is considered an implementation detail which may change in the future -- which could potentially require changing any code type-hinting on it. -- 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 --- ## #53173 — Stas Malyshev — 2011-06-07T18:50:47+00:00 URL: https://externals.io/message/53074#53173 · In reply to: #53142 Hi! > Am I now supposed to create a new thread with [RFC] in the subject, > wait for minimum 2 weeks, and then create a poll somewhere on the wiki > and create new thread with [VOTE] in subject, and wait for another > 2weeks and then if accepted by 50%+1 php.net developer, and 60% of the > community votes, then I can commit? > Thats the current rules of the game? Not really, we never had 50%+1 rule and I really hope we never will. But the rest is close to what is being currently proposed. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #53175 — david.zuelke@bitextender.com — 2011-06-07T19:04:22+00:00 URL: https://externals.io/message/53074#53175 · In reply to: #53125 > > > […] > > The whole point is that callables are generally not constructed from > user input, they're hardcoded in the code somewhere, and so if a fatal > error occurs, the developer notices it, hopefully during development. > > With is_readable, a file can be anywhere, anytime, readable or not, it > depends on the environment the code runs on, and not on the code > itself, so it's not deterministic and you should therefore be able to > easily handle this gracefully. Precisely. I'd love to see a "callable" type hint too. And a "scalar" one while we're at it ;) David --- ## #53176 — Stas Malyshev — 2011-06-07T19:12:46+00:00 URL: https://externals.io/message/53074#53176 · In reply to: #53159 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 --- Next page: https://externals.io/message/53074.md?page=2