POC https://wiki.php.net/rfc/function-composition#18800
POC https://wiki.php.net/rfc/function-composition#18800sgolemon wants to merge 5 commits into
Conversation
|
Needs more testing, and as @Crell already noted on discord, there's a gap for: class A {
public function __invoke($x) { return $x; }
}
$cb = (new A) + (new A);As these have no class level overloading of the add operator. |
| closure_handlers.get_debug_info = zend_closure_get_debug_info; | ||
| closure_handlers.get_closure = zend_closure_get_closure; | ||
| closure_handlers.get_gc = zend_closure_get_gc; | ||
| closure_handlers.do_operation = zend_closure_do_operation; |
There was a problem hiding this comment.
Interesting! That's not at all how I would have thought to do it.
If I follow, this is implemented as an operator override on closures, rather than special casing the operator itself, yes?
There was a problem hiding this comment.
Correct. When the engine encounts a binary op (like addition) involving one of more objects, it checks them for do_operation overloads (with priority to the lhs) and asks the object to perform the addition itself. The first one which reports SUCCESS and populates result wins. So if you added (gmp) + (closure), then GMP would try to do the addition, have no idea what to make of a closure, and fail, and the closure would do the same (not knowing what to do with a gmp), and you'd wind up with an error.
There was a problem hiding this comment.
That said, an explicit engine level overload of the binary-op helper would allow us to cover situations like this one.
e.g.
diff --git a/Zend/zend_operators.c b/Zend/zend_operators.c
index 140734d1b96..b9f9629c616 100644
--- a/Zend/zend_operators.c
+++ b/Zend/zend_operators.c
@@ -1128,6 +1128,11 @@ static zend_never_inline zend_result ZEND_FASTCALL add_function_slow(zval *resul
ZEND_TRY_BINARY_OBJECT_OPERATION(ZEND_ADD);
+ if (((Z_TYPE_P(op1) == IS_OBJECT) || (Z_TYPE_P(op2) == IS_OBJECT)) &&
+ (zend_composed_callable_new_from_pair(result, op1, op2) == SUCCESS)) {
+ return SUCCESS;
+ }
+
zval op1_copy, op2_copy;
if (UNEXPECTED(zendi_try_convert_scalar_to_number(op1, &op1_copy) == FAILURE)
|| UNEXPECTED(zendi_try_convert_scalar_to_number(op2, &op2_copy) == FAILURE)) {There was a problem hiding this comment.
Heck, could even cover the $cb = 'strtolower' + 'strrev'; kind of cases that way, if you wanted to go for maximum magic (I don't).
There was a problem hiding this comment.
Correct. When the engine encounts a binary op (like addition) involving one of more objects, it checks them for
do_operationoverloads (with priority to the lhs) and asks the object to perform the addition itself. The first one which reportsSUCCESSand populatesresultwins. So if you added(gmp) + (closure), then GMP would try to do the addition, have no idea what to make of a closure, and fail, and the closure would do the same (not knowing what to do with a gmp), and you'd wind up with an error.
Our operator overloading mechanism is far from robust, and GMP used to throw its own exception and not delegate properly to the fallback.
Moreover, behaviour with other values might still be somewhat broken, this really needs tests with every possible scalar and null as the LHS and RHS of +
|
Hm, I can't even get this to compile, even with |
|
I don't really understand why we need a new CE? Why can't the composition of two Closures not just return a new Closure? |
You need to rebuild and rerun configure since there's a new build target. |
Could. I just chose this route. I would say that it allows things like |
|
@Crell Brought your tests in and fixed a bug I must have introduced right before my original push. |
No description provided.