Re: [PHP-DEV] Callable typehint
On Tue, Jun 7, 2011 at 8:50 PM, Stas Malyshev smalys...@sugarcrm.comwrote: 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. 50%+1 is the required majority for changes which doesn't affect the syntax or the language in some important way(I agree that this RFC would need 2/3 of the votes as it introduces a new typehint), on the other hand we have no precedence for the community votes. 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. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Callable typehint
On 28 May 2013 07:00, Ferenc Kovacs tyr...@gmail.com wrote: 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
Re: [PHP-DEV] Callable typehint
2013.05.28. 8:48, Peter Cowburn petercowb...@gmail.com ezt írta: On 28 May 2013 07:00, Ferenc Kovacs tyr...@gmail.com wrote: 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 I blame the morning. :/
Re: [PHP-DEV] Callable typehint
On Tue, Jun 7, 2011 at 1:02 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
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/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
On Mon, Jun 6, 2011 at 22:49, Christopher Jones christopher.jo...@oracle.com wrote: On 06/06/2011 12:41 PM, Hannes Magnusson wrote: 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
On 7 June 2011 15:00, Hannes Magnusson bj...@php.net wrote: On Mon, Jun 6, 2011 at 22:49, Christopher Jones christopher.jo...@oracle.com wrote: On 06/06/2011 12:41 PM, Hannes Magnusson wrote: 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
On Tue, Jun 7, 2011 at 16:04, Richard Quadling rquadl...@gmail.com wrote: On 7 June 2011 15:00, Hannes Magnusson bj...@php.net wrote: On Mon, Jun 6, 2011 at 22:49, Christopher Jones christopher.jo...@oracle.com wrote: On 06/06/2011 12:41 PM, Hannes Magnusson wrote: 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. 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. ;) That RFC process thread just became to much to pay attention to, so I'm unsure what the status of it is. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
On 2011-06-07, Hannes Magnusson bj...@php.net wrote: On Mon, Jun 6, 2011 at 22:49, Christopher Jones christopher.jo...@oracle.com wrote: On 06/06/2011 12:41 PM, Hannes Magnusson wrote: 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. 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| 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 typehint
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
On 07.06.2011, at 12:09, Jordi Boggiano wrote:
On Tue, Jun 7, 2011 at 1:02 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
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.
Precisely.
I'd love to see a callable type hint too. And a scalar one while we're at
it ;)
David
smime.p7s
Description: S/MIME cryptographic signature
[PHP-DEV] Callable typehint
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
Index: Zend/zend.h
===
--- Zend/zend.h (revision 311867)
+++ Zend/zend.h (working copy)
@@ -573,6 +573,7 @@
#define IS_RESOURCE7
#define IS_CONSTANT8
#define IS_CONSTANT_ARRAY 9
+#define IS_CALLABLE10
/* Ugly hack to support constants as static array indices */
#define IS_CONSTANT_TYPE_MASK 0x00f
Index: Zend/zend_execute.c
===
--- Zend/zend_execute.c (revision 311867)
+++ Zend/zend_execute.c (working copy)
@@ -626,13 +626,24 @@
need_msg = zend_verify_arg_class_kind(cur_arg_info,
fetch_type, class_name, ce TSRMLS_CC);
return zend_verify_arg_error(E_RECOVERABLE_ERROR, zf,
arg_num, need_msg, class_name, zend_zval_type_name(arg), TSRMLS_CC);
}
- } else if (cur_arg_info-type_hint cur_arg_info-type_hint ==
IS_ARRAY) {
- if (!arg) {
- return zend_verify_arg_error(E_RECOVERABLE_ERROR, zf,
arg_num, be of the type array, , none, TSRMLS_CC);
- }
+ } else if (cur_arg_info-type_hint) {
+ switch(cur_arg_info-type_hint) {
+ case IS_ARRAY:
+ if (!arg) {
+ return
zend_verify_arg_error(E_RECOVERABLE_ERROR, zf, arg_num, be of the type array,
, none, TSRMLS_CC);
+ }
- if (Z_TYPE_P(arg) != IS_ARRAY (Z_TYPE_P(arg) != IS_NULL ||
!cur_arg_info-allow_null)) {
- return zend_verify_arg_error(E_RECOVERABLE_ERROR, zf,
arg_num, be of the type array, , zend_zval_type_name(arg), TSRMLS_CC);
+ if (Z_TYPE_P(arg) != IS_ARRAY (Z_TYPE_P(arg) !=
IS_NULL || !cur_arg_info-allow_null)) {
+ return
zend_verify_arg_error(E_RECOVERABLE_ERROR, zf, arg_num, be of the type array,
, zend_zval_type_name(arg), TSRMLS_CC);
+ }
+ break;
+ case IS_CALLABLE:
+ if (!zend_is_callable(arg, IS_CALLABLE_CHECK_SILENT,
NULL) (Z_TYPE_P(arg) != IS_NULL || !cur_arg_info-allow_null)) {
+ return
zend_verify_arg_error(E_RECOVERABLE_ERROR, zf, arg_num, be callable, ,
zend_zval_type_name(arg), TSRMLS_CC);
+ }
+ break;
+ default:
+ zend_error(E_ERROR, Unknown typehint);
}
}
return 1;
Index: Zend/zend_language_scanner.l
===
--- Zend/zend_language_scanner.l(revision 311867)
+++ Zend/zend_language_scanner.l(working copy)
@@ -1310,6 +1310,10 @@
return T_ARRAY;
}
+ST_IN_SCRIPTINGcallable {
+ return T_CALLABLE;
+}
+
ST_IN_SCRIPTING++ {
return T_INC;
}
Index: Zend/zend_compile.c
===
--- Zend/zend_compile.c (revision 311867)
+++ Zend/zend_compile.c (working copy)
@@ -1849,28 +1849,40 @@
cur_arg_info-allow_null = 0;
if (class_type-u.constant.type != IS_NULL) {
- cur_arg_info-type_hint = IS_OBJECT;
- if (ZEND_FETCH_CLASS_DEFAULT ==
zend_get_class_fetch_type(Z_STRVAL(class_type-u.constant),
Z_STRLEN(class_type-u.constant))) {
- zend_resolve_class_name(class_type,
opline-extended_value, 1 TSRMLS_CC);
- }
- class_type-u.constant.value.str.val =
zend_new_interned_string(class_type-u.constant.value.str.val,
class_type-u.constant.value.str.len + 1, 1 TSRMLS_CC);
- cur_arg_info-class_name =
class_type-u.constant.value.str.val;
- cur_arg_info-class_name_len =
class_type-u.constant.value.str.len;
- if (op == ZEND_RECV_INIT) {
- if (Z_TYPE(initialization-u.constant) ==
IS_NULL || (Z_TYPE(initialization-u.constant) == IS_CONSTANT
!strcasecmp(Z_STRVAL(initialization-u.constant), NULL))) {
- cur_arg_info-allow_null = 1;
- } else {
- zend_error(E_COMPILE_ERROR, Default
value for parameters with a class type hint can only be NULL);
+ if (class_type-u.constant.type == IS_ARRAY) {
+ cur_arg_info-type_hint = IS_ARRAY;
+ if (op == ZEND_RECV_INIT) {
+ if
Re: [PHP-DEV] Callable typehint
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
On Mon, Jun 6, 2011 at 22:35, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! See attached patch+phpt; Any objections to include it in 5.4? 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
On 06/06/2011 12:41 PM, Hannes Magnusson wrote: 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.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
On 2011-06-06, Stas Malyshev smalys...@sugarcrm.com 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| 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 typehint
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 Oapos;Phinney weierophin...@php.net
wrote:
On 2011-06-06, Stas Malyshev smalys...@sugarcrm.com 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 | 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 typehint
On 2011-06-06, Pierre Joye pierre@gmail.com wrote:
--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 Oapos;Phinney weierophin...@php.net
wrote:
On 2011-06-06, Stas Malyshev smalys...@sugarcrm.com 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 | 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
--0016e6de0029ddc06f04a5129914--
--
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 typehint
Hi, On Mon, Jun 6, 2011 at 22:35, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! See attached patch+phpt; Any objections to include it in 5.4? 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Etienne Kneuss http://www.colder.ch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
Hello,
On Mon, Jun 6, 2011 at 12:41 PM, Hannes Magnusson
hannes.magnus...@gmail.com 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
Hello,
On Mon, Jun 6, 2011 at 3:51 PM, Chris Stockton
chrisstockto...@gmail.com wrote:
Hello,
On Mon, Jun 6, 2011 at 12:41 PM, Hannes Magnusson
hannes.magnus...@gmail.com 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
s/Closure/Callable/g
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
On Mon, Jun 6, 2011 at 9:41 PM, Hannes Magnusson hannes.magnus...@gmail.com
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
+1 but please create an RFC for it, or we will argue this to death.
Tyrael
Re: [PHP-DEV] Callable typehint
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
Hi Stas,
On Mon, Jun 6, 2011 at 4:02 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
On Mon, 6 Jun 2011, 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.
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
Martin Scotta
On Mon, Jun 6, 2011 at 8:02 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
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();
}
trol?
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
