The newly introduced DynamicFunctionStorageProviderInterface makes it possible to dynamically create templates based on the provided function. This allows us to count the amount of arguments (e.g. 3) and create 4 dynamic templates that are linking up the pipe parameters like this:
param1 = closure(T1): T2
param2 = closure(T2): T3
param3 = closure(T3): T4
The resulting closure that is coming out pipe() will then be:
closure(T1): T4
In previous implementation, we frequently had to tell psalm the types were mixed, because we did not know better.
By doing it this way, we rely on psalm being able to infer the templates for us!
(Thanks to the amazing work of @klimick)
Possible other use-case
Based on this principle, we can add e.g. new partial_left and partial_right functions that are checked by psalm instead of runtime. I would only add this if we were able to use the function as string (e.g. through dynamic define's as you proposed a while back.
For example:
partial_right(Vec\map, Str\trim)($items) // -> closure(list<string>): list<string>
// or
partial_right(Vec\map::class, Str\trim::class)($items)
Psalm v5 is out!
This PR contains:
More info about the dynamic storage:
-> Testcases in PSL: https://github.com/azjezz/psl/pull/372
Why is this better?
The newly introduced
DynamicFunctionStorageProviderInterfacemakes it possible to dynamically create templates based on the provided function. This allows us to count the amount of arguments (e.g. 3) and create 4 dynamic templates that are linking up the pipe parameters like this:closure(T1): T2closure(T2): T3closure(T3): T4The resulting closure that is coming out pipe() will then be:
closure(T1): T4In previous implementation, we frequently had to tell psalm the types were mixed, because we did not know better. By doing it this way, we rely on psalm being able to infer the templates for us!
(Thanks to the amazing work of @klimick)
Possible other use-case
Based on this principle, we can add e.g. new partial_left and partial_right functions that are checked by psalm instead of runtime. I would only add this if we were able to use the function as string (e.g. through dynamic define's as you proposed a while back. For example:
More info:
The cool thing about validating this in psalm, is that we do not require additional runtime validations. (or at least theoretically)