Re: [RFC] [Vote] Callable types (now: Callable prototypes)

On Tue, 24 May 2016 02:24:12 +0300, Dan Ackroyd <danack@basereality.com> wrote:

Hi Nikita, On 23 May 2016 at 15:27, Nikita Nefedov <inefedor@gmail.com> wrote:

With this message I'd like to go to vote with the Callable prototypes RFC targeted at 7.1: https://wiki.php.net/rfc/callable-types

To explain my vote - I think we definitely need to be able to specify the signatures of callables in PHP, and I would very probably support either a 'typedef' RFC, or an expansion of current functional type (i.e. invokables) to be easier to use with functions, but I just couldn't possibly vote for an RFC that means people would sometimes write code similar to this:

    function foo(int $a, int $b,

callable(callable(callable(callable(int, int):int $zebranky, int):int $pik, int):int $fot, int):int $zot): int {

        return $zot($a, $b);
    }

to use the feature of the RFC. I realise that is an extreme case, but I think that splitting where a type is defined (with a name) and the place where it is used to be separate places, is one of the things that the design of PHP got right. It makes it easier to read code, even if it makes the language feel less 'powerful' than other languages. cheers Dan

Morning Dan, I think we definitely would need type aliases. But I also hoped for union types to get in, so that after these two we could have another RFC that would do typedefs for callables and for unions. Doing typedefs for callables only seems too narrow. People would probably vote 'no' for that RFC because apart from creating new syntax for callables it would also create a flavour of typedef that works in limited scope only. And that seems completely fair, typedef is another feature. And even with typedefs I see no reason not to support inline callable prots. Do you remember 'Arbitrary expressions' RFC? I look at it just like at expressions, and I think there's a need for any possible type to be expressed directly in a parameter typehint. Making code more readable would be a responsibility of a user who would decide whether he needs to use function signatures or not. Regarding Joe's functional interfaces, I wish they were passing vote. They can be a nice addition (and a pretty simple one) to the language. I also think they are not related to this RFC, as their usage is completely different... What I am aiming at with this (and possibly next) RFC is to make function composition work better and functional interfaces don't touch this subject at all. The fact that function needs to opt-in and the fact that the signature of a function needs to be completely same as in interface (so no variance) makes it useless in cases where callable prototypes should be used instead.

I realise that is an extreme case, but I think that splitting where a type is defined (with a name) and the place where it is used to be separate places

I think so too but "callable(int): int" is not defining a type, it is using it. On the other hand "callable" here is a type constructor. If we would have generics of some form this would be similar to: "Function<int, int>" where you don't define a type but you create it passing "int, int" arguments to a type constructor (or a template, or a generic class) which results in a type in the end. When you get parametrized types there's a natural need for parameterizing them in place...