Hello,
thank you for the comment! Yes, indeed I was raising a discussion on whether we
should allow making typed callable properties for improved language's
consistency (given that parameter/return type hints can be set to callable). As
one of the solutions, I mentioned that we could just ignore the
scope/context-dependent problems for the time being.
In regards to your comment on `Closure::fromCallable()`, I do also agree that
it is quite verbose and a potential performance hit and as such, this isn't the
way to go. As an example, let's imagine a framework that allows registering
routes to callables. If we wanted to completely type-hint the entire framework,
we would have to make typed Closure properties and in the `addRoute()` function
used `Closure::fromCallable()` to convert every single callable into a closure
object. So, huge applications with thousands of routes would be potentially
affected by this additional overhead.
Best regards,
Benas Seliuginas
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, April 22, 2020 7:30 PM, Rowan Tommins <rowan.coll...@gmail.com>
wrote:
> 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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
