On 22/04/2020 16:01, Michał Brzuchalski wrote:
I agree, a callable brings as much information as a resource type - you
know the type
but are unable to use it without additional information.
While this is true, it's somewhat orthogonal to the question Benas
raised in this thread - namely, how to handle values that are callable
in one scope but not another.
That is, is the following code valid (error-free) or not?
delegate Reducer (?int $sum, int $item = 0): int;
class X {
private static function myPrivateMethod(?int $sum, int $item = 0):
int {
return 0;
}
public static function runReducer(Reducer $r) {
return $r(0, 0);
}
}
echo X::bar(['X', 'myPrivateMethod']);
The equivalent code with a type constraint of "callable" currently runs
fine, even though passing the same value to a different function would
fail due to scoping. Making the delegate-constrained version throw an
error for any private or protected method would just trade one
inconsistency for another.
A more reasonable restriction, IMO, would be to say that delegates only
match Closure instances (and possibly other objects with a public
__invoke method), not the various string and array syntaxes that
"callable" currently allows. The case above would then need to bind the
private method into a closure that is callable everywhere, e.g. using
Closure::fromCallable([self::class, 'myPrivateMethod']);
The obvious downside is that Closure::fromCallable is both verbose and a
potential performance hit. So it seems we're back again to wanting a new
syntax to succinctly and optimally generate such a closure. For
instance, in the discussion of ::func, one suggestion was
"$closure={self::myPrivateMethod};" and more recently it was mentioned
that a variant of partial application is to not actually bind anything,
and write "$closure=self::myPrivateMethod(?, ?);"
Regards,
--
Rowan Tommins (né Collins)
[IMSoP]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
