Re: Typed callable properties

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.collins@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