Re: [PHP-DEV] Callable type
2011/7/10 Johannes Schlüter johan...@schlueters.de:
Hi,
On Wed, 2011-06-08 at 12:04 +0200, Johannes Schlüter wrote:
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.
Any comments to this? - I didn't see an answer before the votes were
opened.
Voting is open on this? I don't think I ever had the time to integrate
all the QA from this thread to the RFC.
If you typehint on Closure, you don't know if it takes 0 or 10
parameters either.
I don't think that is the point to know that either.
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
Hi! On 7/11/11 1:22 AM, Hannes Magnusson wrote: Voting is open on this? I don't think I ever had the time to integrate all the QA from this thread to the RFC. If you think it's premature, we can postpone it. I've announced the ballot on the list, but apparently not everybody is reading it ;) -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
On Mon, Jul 11, 2011 at 10:27, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! On 7/11/11 1:22 AM, Hannes Magnusson wrote: Voting is open on this? I don't think I ever had the time to integrate all the QA from this thread to the RFC. If you think it's premature, we can postpone it. I've announced the ballot on the list, but apparently not everybody is reading it ;) No no. Especially after seeing the currents votes ;) Didn't notice your thread until just now. I thought individual RFCs would be voted on first (into trunk), and then there would be a vote on merging things from trunk. This sort of heavy voting process is however new to me, will take some time understanding and getting used to all the new rules around here. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
2011/7/11 Hannes Magnusson hannes.magnus...@gmail.com:
2011/7/10 Johannes Schlüter johan...@schlueters.de:
Hi,
On Wed, 2011-06-08 at 12:04 +0200, Johannes Schlüter wrote:
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.
Any comments to this? - I didn't see an answer before the votes were
opened.
Voting is open on this? I don't think I ever had the time to integrate
all the QA from this thread to the RFC.
The related vote is in the Voting for 5.4 features vote [1], which
asks do we want to include this feature in 5.4 release? (and oddly,
a preferred choice of callback/callable/neither). Voting on the RFC
itself, the implementation details and such, will obviously be your
call. Whether it makes sense to say yes we want this in 5.4 before a
more general vote on the RFC itself (yes, we want this), I'm not
sure.
[1] https://wiki.php.net/todo/php54/vote
If you typehint on Closure, you don't know if it takes 0 or 10
parameters either.
I don't think that is the point to know that either.
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
Hi! On 7/11/11 1:38 AM, Hannes Magnusson wrote: I thought individual RFCs would be voted on first (into trunk), and then there would be a vote on merging things from trunk. This sort of heavy voting process is however new to me, will take some time understanding and getting used to all the new rules around here. Well, this is kind of exceptional, because we had many things that were discussed before we had RFC process and voting process decided on, and we are in the release process. After we've cleaned our plate with this vote, new ones would be individual and according to the new RFC. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
Hi,
On Wed, 2011-06-08 at 12:04 +0200, Johannes Schlüter wrote:
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.
Any comments to this? - I didn't see an answer before the votes were
opened.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
Hi!
On 7/10/11 12:02 PM, Johannes Schlüter wrote:
I can call it in some way. It won't ensure that the signature is
compatible with what I expect.
Well, it's like array type - you know it's an array but you can't know
if it contains certain element that you expect, for example. As I'm not
a big fan of strict typing in PHP anyway, I can't really defend this
thing, but this is nothing new - other type restrictions don't guarantee
you the code would work properly either, they only guarantee the type.
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
Indeed, E_RECOVERABLE is more or less useless - they are only marginally
better than E_ERROR since error handler could be invoked on it. I do not
know why people think E_RECOVERABLE makes anything better.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
We have the situation in the docs that parameters declared as arrays do not follow the typehinting rules, but parameters as class names do. Re-using the callback from the docs could get confusing when extensions start to typehint on it, but not the core.. I think there is a subtle difference between a callback, and a callable. In javascript for example, callback is something that is executed on certain events onsuccess is the typical example. There is nothing that says the callable parameter gets executed as a part of an event, and I think the default usecase would be to execute it right away (f.e. filtering data). I think I would prefer callable, but I could live with either. -Hannes On Tue, Jun 7, 2011 at 23:41, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2011-06-07, dukeofgaming dukeofgam...@gmail.com wrote: --0016e68ee3e4bc4b0e04a525bac6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 for callable, it is really more consistent. I was actually agreeing With David and Stas that callback was more consistent, and casting my vote for that. On Tue, Jun 7, 2011 at 3:44 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2011-06-07, David Z=FClke david.zue...@bitextender.com wrote: On 07.06.2011, at 22:31, Stas Malyshev wrote: callback is callable, the opposite could not be true. a string --or a closure-- is callable, but the string is not a callback According to our docs, which were out there for years, it is. One of the main and widespread complaints about PHP is the lack of any system in naming, design and documentation, it is sad to see how many people want to make it worse instead of making it better +1. I'm thinking it should be callback, or the docs should be adjusted. callable arguably does make more sense, but either way, it needs to be consistent, that's what matters most. Agreed, here. callback is the usage throughout the documentation to refer to anything that passes is_callable(). -- Matthew Weier O'Phinney Project Lead | matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
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.
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.
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 :)
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
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
2011/6/8 Hannes Magnusson hannes.magnus...@gmail.com: We have the situation in the docs that parameters declared as arrays do not follow the typehinting rules, but parameters as class names do. Re-using the callback from the docs could get confusing when extensions start to typehint on it, but not the core.. I think there is a subtle difference between a callback, and a callable. In javascript for example, callback is something that is executed on certain events onsuccess is the typical example. There is nothing that says the callable parameter gets executed as a part of an event, and I think the default usecase would be to execute it right away (f.e. filtering data). I think I would prefer callable, but I could live with either. Wikipedia defines callback as a reference to executable code, or a piece of executable code, that is passed as an argument to other code. So there's no event meaning put by default, it's just very often seen callback's usage in javascript. I just like callback term more :) -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
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.phpq=lang:php%20%22class%20callable%22sa=Ncd=9ct=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.phpq=lang:php%20%22class%20callback%22sa=Ncd=11ct=rc
http://google.com/codesearch/p?hl=en#PbKZfG2CZcc/trunk/phpQuery/phpQuery/Callback.phpq=lang:php%20%22class%20callback%22sa=Ncd=12ct=rcl=29
http://google.com/codesearch/p?hl=en#f6tUYQTbHns/trunk/framework/activerecord/lib/CallBack.phpq=lang:php%20%22class%20callback%22sa=Ncd=21ct=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
Re: [PHP-DEV] Callable type
2011/6/8 Johannes Schlüter johan...@schlueters.de:
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 { }
No. 'callable' is a parser token.
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 */
}
}
Etienne pointed out that default values for arrays can actually contain values..
I actually had no idea.
I suppose we then need to support default values for an array callable.
But yes, a callable can have the default value of null, following the
rules of class hinting.
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
On 8 June 2011 09:47, Alexey Shein con...@gmail.com wrote:
2011/6/8 Hannes Magnusson hannes.magnus...@gmail.com:
We have the situation in the docs that parameters declared as arrays
do not follow the typehinting rules, but parameters as class names do.
Re-using the callback from the docs could get confusing when
extensions start to typehint on it, but not the core..
I think there is a subtle difference between a callback, and a callable.
In javascript for example, callback is something that is executed on
certain events onsuccess is the typical example.
There is nothing that says the callable parameter gets executed as a
part of an event, and I think the default usecase would be to execute
it right away (f.e. filtering data).
I think I would prefer callable, but I could live with either.
Wikipedia defines callback as a reference to executable code, or a
piece of executable code, that is passed as an argument to other
code. So there's no event meaning put by default, it's just very
often seen callback's usage in javascript.
I just like callback term more :)
An interesting issue here.
Closures, classes with an __invoke method and strings containing
existing function names all pass is_callable() and can be called using
().
But, array('class', 'method') also passes is_callable, but isn't a callback.
http://pastebin.com/Yb5nJ8DB
outputs ...
object is callable
Invoked : Wed, 08 Jun 2011 11:24:09 +0100
object is callable
Closure : Wed, 08 Jun 2011 11:24:09 +0100
string is callable
Wed, 08 Jun 2011 11:24:09 +0100
array is callable
Handling Array via call_user_func
Func array : Wed, 08 Jun 2011 11:24:09 +0100
So, callable and callbacks are 2 different things.
Callable
1 - closures.
2 - classes with an __invoke method.
3 - strings to an existing function.
4 - array('class', 'method')
Callbacks
Only 1, 2 and 3 from the above list.
If you try to use $funcarray(), you get the following fatal error ...
Fatal error: Function name must be a string
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
On Wed, 2011-06-08 at 12:17 +0200, Hannes Magnusson wrote:
A callable wouldn't be fully featured type.
Which means that
class callable { }
No. 'callable' is a parser token.
Which has larger implications. This break code where people use callable
as constant, property, function or method name.
This seems to hit symfony and a few others.
http://google.com/codesearch?hl=enlr=q=lang%3Aphp+%22-%3Ecallable%
22sbtn=Search
(yes breaking stuff can be fine, but we should at least be aware of
it ;-) )
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 */
}
}
Etienne pointed out that default values for arrays can actually contain
values..
I actually had no idea.
I suppose we then need to support default values for an array callable.
As I pointed out on IRC I'm not sure that's good, unless we want
closures as defaults, too. Which we probably won't like.
But yes, a callable can have the default value of null, following the
rules of class hinting.
Good.
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
On Wed, Jun 8, 2011 at 12:27, Richard Quadling rquadl...@gmail.com wrote:
On 8 June 2011 09:47, Alexey Shein con...@gmail.com wrote:
2011/6/8 Hannes Magnusson hannes.magnus...@gmail.com:
We have the situation in the docs that parameters declared as arrays
do not follow the typehinting rules, but parameters as class names do.
Re-using the callback from the docs could get confusing when
extensions start to typehint on it, but not the core..
I think there is a subtle difference between a callback, and a callable.
In javascript for example, callback is something that is executed on
certain events onsuccess is the typical example.
There is nothing that says the callable parameter gets executed as a
part of an event, and I think the default usecase would be to execute
it right away (f.e. filtering data).
I think I would prefer callable, but I could live with either.
Wikipedia defines callback as a reference to executable code, or a
piece of executable code, that is passed as an argument to other
code. So there's no event meaning put by default, it's just very
often seen callback's usage in javascript.
I just like callback term more :)
An interesting issue here.
Closures, classes with an __invoke method and strings containing
existing function names all pass is_callable() and can be called using
().
But, array('class', 'method') also passes is_callable, but isn't a callback.
It is after Felipes recent commit introducing $array();
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
On Wed, 2011-06-08 at 11:27 +0100, Richard Quadling wrote:
If you try to use $funcarray(), you get the following fatal error ...
Fatal error: Function name must be a string
This is fixed. See thread
From: Felipe Pena felipe...@gmail.com
To: internals internals@lists.php.net
Subject:[PHP-DEV] $arr = array('Hello', 'world'); $arr();
Date: Sun, 5 Jun 2011 12:52:45 -0300 (06/ 5/11 05:52:45 PM)
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
2011/6/8 Johannes Schlüter johan...@schlueters.de:
On Wed, 2011-06-08 at 11:27 +0100, Richard Quadling wrote:
If you try to use $funcarray(), you get the following fatal error ...
Fatal error: Function name must be a string
This is fixed. See thread
From: Felipe Pena felipe...@gmail.com
To: internals internals@lists.php.net
Subject: [PHP-DEV] $arr = array('Hello', 'world'); $arr();
Date: Sun, 5 Jun 2011 12:52:45 -0300 (06/ 5/11 05:52:45 PM)
johannes
Thank you.
--
Richard Quadling
Twitter : EE : Zend : PHPDoc
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
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.
Unless I mis-read what you said, we already have default array values
for array type-hinting:
function foo(array $array = array('bar', 'baz')) {
var_dump($array);
}
foo();
foo(array());
Works perfectly for me on 5.3.6...
2011/6/8 Hannes Magnusson hannes.magnus...@gmail.com:
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.
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.
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 :)
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
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
Martin Scotta On Wed, Jun 8, 2011 at 5:47 AM, Alexey Shein con...@gmail.com wrote: 2011/6/8 Hannes Magnusson hannes.magnus...@gmail.com: We have the situation in the docs that parameters declared as arrays do not follow the typehinting rules, but parameters as class names do. Re-using the callback from the docs could get confusing when extensions start to typehint on it, but not the core.. I think there is a subtle difference between a callback, and a callable. In javascript for example, callback is something that is executed on certain events onsuccess is the typical example. There is nothing that says the callable parameter gets executed as a part of an event, and I think the default usecase would be to execute it right away (f.e. filtering data). I think I would prefer callable, but I could live with either. Wikipedia defines callback as a reference to executable code, or a piece of executable code, that is passed as an argument to other code. So there's no event meaning put by default, it's just very often seen callback's usage in javascript. I just like callback term more :) so 'strpos' is not a reference nor a piece of executable code, it's just the name of a function, which is callable, although we can argue if the function name could be seen as a reference to the code -- Regards, Shein Alexey -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
Martin Scotta
On Wed, Jun 8, 2011 at 10:31 AM, Anthony Ferrara ircmax...@gmail.comwrote:
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.
Unless I mis-read what you said, we already have default array values
for array type-hinting:
function foo(array $array = array('bar', 'baz')) {
var_dump($array);
}
foo();
foo(array());
Works perfectly for me on 5.3.6...
it works since long time ago
2011/6/8 Hannes Magnusson hannes.magnus...@gmail.com:
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.
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.
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 :)
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
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
He means
function foo(callback derp = array('MyClass', 'ohai')) { ... }
David
On 08.06.2011, at 15:31, Anthony Ferrara wrote:
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.
Unless I mis-read what you said, we already have default array values
for array type-hinting:
function foo(array $array = array('bar', 'baz')) {
var_dump($array);
}
foo();
foo(array());
Works perfectly for me on 5.3.6...
2011/6/8 Hannes Magnusson hannes.magnus...@gmail.com:
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.
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.
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 :)
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
-Hannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] Callable type
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
On 07.06.2011, at 21:12, Stas Malyshev wrote: 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 smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Callable type
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 On Tue, Jun 7, 2011 at 3:12 PM, Stas Malyshev smalys...@sugarcrm.com 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 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
callback is callable, the opposite could not be true. a string --or a closure-- is callable, but the string is not a callback IMHO callable fits better. Martin Scotta On Tue, Jun 7, 2011 at 4:28 PM, David Zülke david.zue...@bitextender.comwrote: On 07.06.2011, at 21:12, Stas Malyshev wrote: 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
Re: [PHP-DEV] Callable type
Hi! callback is callable, the opposite could not be true. a string --or a closure-- is callable, but the string is not a callback According to our docs, which were out there for years, it is. One of the main and widespread complaints about PHP is the lack of any system in naming, design and documentation, it is sad to see how many people want to make it worse instead of making it better. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
On 07.06.2011, at 22:31, Stas Malyshev wrote: Hi! callback is callable, the opposite could not be true. a string --or a closure-- is callable, but the string is not a callback According to our docs, which were out there for years, it is. One of the main and widespread complaints about PHP is the lack of any system in naming, design and documentation, it is sad to see how many people want to make it worse instead of making it better +1. I'm thinking it should be callback, or the docs should be adjusted. callable arguably does make more sense, but either way, it needs to be consistent, that's what matters most. David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Callable type
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, On Tue, Jun 7, 2011 at 9:12 PM, Stas Malyshev smalys...@sugarcrm.com 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 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
To be honest: everybody knows what you mean when you say callback. Callable sounds more like the name of an interface. On Tue, 2011-06-07 at 22:32 +0200, David Zülke wrote: On 07.06.2011, at 22:31, Stas Malyshev wrote: Hi! callback is callable, the opposite could not be true. a string --or a closure-- is callable, but the string is not a callback According to our docs, which were out there for years, it is. One of the main and widespread complaints about PHP is the lack of any system in naming, design and documentation, it is sad to see how many people want to make it worse instead of making it better +1. I'm thinking it should be callback, or the docs should be adjusted. callable arguably does make more sense, but either way, it needs to be consistent, that's what matters most. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
On 2011-06-07, David Zülke david.zue...@bitextender.com wrote: On 07.06.2011, at 22:31, Stas Malyshev wrote: Hi! callback is callable, the opposite could not be true. a string --or a closure-- is callable, but the string is not a callback According to our docs, which were out there for years, it is. One of the main and widespread complaints about PHP is the lack of any system in naming, design and documentation, it is sad to see how many people want to make it worse instead of making it better +1. I'm thinking it should be callback, or the docs should be adjusted. callable arguably does make more sense, but either way, it needs to be consistent, that's what matters most. Agreed, here. callback is the usage throughout the documentation to refer to anything that passes is_callable(). -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
+1 for callable, it is really more consistent. On Tue, Jun 7, 2011 at 3:44 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2011-06-07, David Zülke david.zue...@bitextender.com wrote: On 07.06.2011, at 22:31, Stas Malyshev wrote: Hi! callback is callable, the opposite could not be true. a string --or a closure-- is callable, but the string is not a callback According to our docs, which were out there for years, it is. One of the main and widespread complaints about PHP is the lack of any system in naming, design and documentation, it is sad to see how many people want to make it worse instead of making it better +1. I'm thinking it should be callback, or the docs should be adjusted. callable arguably does make more sense, but either way, it needs to be consistent, that's what matters most. Agreed, here. callback is the usage throughout the documentation to refer to anything that passes is_callable(). -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
On 2011-06-07, dukeofgaming dukeofgam...@gmail.com wrote: --0016e68ee3e4bc4b0e04a525bac6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 for callable, it is really more consistent. I was actually agreeing With David and Stas that callback was more consistent, and casting my vote for that. On Tue, Jun 7, 2011 at 3:44 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2011-06-07, David Z=FClke david.zue...@bitextender.com wrote: On 07.06.2011, at 22:31, Stas Malyshev wrote: callback is callable, the opposite could not be true. a string --or a closure-- is callable, but the string is not a callback According to our docs, which were out there for years, it is. One of the main and widespread complaints about PHP is the lack of any system in naming, design and documentation, it is sad to see how many people want to make it worse instead of making it better +1. I'm thinking it should be callback, or the docs should be adjusted. callable arguably does make more sense, but either way, it needs to be consistent, that's what matters most. Agreed, here. callback is the usage throughout the documentation to refer to anything that passes is_callable(). -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
On Tue, Jun 7, 2011 at 4:41 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2011-06-07, dukeofgaming dukeofgam...@gmail.com wrote: --0016e68ee3e4bc4b0e04a525bac6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 for callable, it is really more consistent. I was actually agreeing With David and Stas that callback was more consistent, and casting my vote for that. Oh. But then, shouldn't is_callable be deprecated for a more consistently named is_callback? Regards, David
Re: [PHP-DEV] Callable type
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)
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
On 08.06.2011, at 00:38, dukeofgaming wrote: On Tue, Jun 7, 2011 at 4:41 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2011-06-07, dukeofgaming dukeofgam...@gmail.com wrote: +1 for callable, it is really more consistent. I was actually agreeing With David and Stas that callback was more consistent, and casting my vote for that. Oh. But then, shouldn't is_callable be deprecated for a more consistently named is_callback? No, because is_callable() also performs visibility checks. Which of course begs the question... should the type hint do the same? David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Callable type
2011/6/8 David Zülke david.zue...@bitextender.com:
On 08.06.2011, at 00:38, dukeofgaming wrote:
On Tue, Jun 7, 2011 at 4:41 PM, Matthew Weier O'Phinney
weierophin...@php.net wrote:
On 2011-06-07, dukeofgaming dukeofgam...@gmail.com wrote:
+1 for callable, it is really more consistent.
I was actually agreeing With David and Stas that callback was more
consistent, and casting my vote for that.
Oh. But then, shouldn't is_callable be deprecated for a more consistently
named is_callback?
No, because is_callable() also performs visibility checks.
Which of course begs the question... should the type hint do the same?
David
+1 to callback (and have mercy on docs/translation people, it's too
much work to search/replace for such a minor difference :))
And yes, two similar terms (callback/callable) will make situation worse.
Plus to Johanness question: will it add runtime performance overhead
on code like this:
function(callback $callback = 'non_existent_function') {}
--
Regards,
Shein Alexey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
