Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:93468
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.217.182 as permitted sender)
Content-Type: text/plain; charset=koi8-r; format=flowed; delsp=yes
To: "Dan Ackroyd" <danack@basereality.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
References: <op.yhw6ft0mc9evq2@nikita-work-box>
 <CA+kxMuTxYP2n5t5x7B1HH0P8x11mAGJaEsBiG7ncvtDMFmnhCg@mail.gmail.com>
Date: Tue, 24 May 2016 09:28:30 +0300
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Message-ID: <op.yhyexsxpc9evq2@nikita-pc>
In-Reply-To: <CA+kxMuTxYP2n5t5x7B1HH0P8x11mAGJaEsBiG7ncvtDMFmnhCg@mail.gmail.com>
User-Agent: Opera Mail/12.17 (Win32)
Subject: Re: [PHP-DEV] [RFC] [Vote] Callable types (now: Callable prototypes)
From: inefedor@gmail.com ("Nikita Nefedov")

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...