Re: Typed callable properties

Hello, thank you for expanding on your comparison of callables to resources. I didn't completely understand what you meant but now I do. Speaking of "dynamic" callables - this is also one of the reasons as to why I believe we shouldn't wait for typedefs and should allow properties to be typed as callable (just like parameters/return type). Don't get me wrong, I fully agree that we should have more strict callables and an ability to specify their signatures if they are static (in a sense that they don't change) and not dynamic. But in cases like the one I mentioned, all we can do is specify that we accept any callable. Best regards, Benas Seliuginas ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, April 22, 2020 8:39 PM, Michał Brzuchalski <michal.brzuchalski@gmail.com> wrote: > Hi Benas, > > my responses below. > > śr., 22 kwi 2020 o 19:17 moliata <moliata@protonmail.com> napisał(a): > >> Hello, >> >> thank you for an opinion as well! While I do fully agree that callable type >> needs to be improved with features such as typedefs, I found a couple of >> problems in your response. >> >> First of all, I wouldn't say that the callable type provides little-to-no >> information like the resource type. A resource can only be made by specific >> functions such as fopen() and are bound to specific use >> cases/implementations >> e. g. MySQL resources are only for MySQL database access. Meanwhile, callables >> can be made "freely" (couldn't find a better word :-)) like integers or >> booleans and also in some cases don't have an exact function signature. One >> such example I mention in the next paragraph. > > I only said that it brings as much value as a resource type in usage context. > > Given a resource type constraint on function argument doesn't say anything to you > as a consumer, you cannot just use that resource without knowledge of its type > the only thing you could do is calling a get_resource_type(resource $resource) function. > > The same applies to callable, given callable like: 'strtolower', > [DateTimeImmutable::class, 'createFromFormat'] > or fn(int $x): $x*2; and when that came to your function with callable type constraint > you also don't know how to use it without some reflection inspection cause the type > doesn't bring much value. > > While fulfilling for eg. delegate gives you guarantee that when a callable/closure is passed it > matches > your expectations and you can use it right away without reflection inspections. > You no longer need additional data to use the variable which applies to callable and resource > as well. > >> Speaking of a snippet you showed, I'm not sure how that implementation would >> work with "dynamic" callables. For example let's assume we have a framework >> that allows registering routes with placeholders to controllers, like this: >> `$router->register('/post/{id}', [$controller, 'show']); // this >> would pass a >> single parameter to the callable` >> `$router->register('/user/{id}/post/{id}', [$controller, >> 'showFromUser']); // >> this would pass two parameters to the callable` >> ...in this case, we can't know how many placeholders/parameters a function can >> have as that depends on how many placeholders are in the string. A framework >> can only resolve these at runtime. > > True. In this case, it'd be hard to create a static constraint for callable/closure check > but actually this is not the case we're looking for. Things where mentioned delegate > match perfectly is the places where your expectations to the callable/closure type > are static and known at the time when writing code. > > Given that in a situation when the input and the output types are known this would bring the > benefit of runtime check before use. > > Cheers, > Michał Brzuchalski