Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:109784
MIME-Version: 1.0
References: <AG6mBe5pFAi6EzBs269tNFsDoOmnW-qjSfHkugdR8AZPM2nRXUuNYl8uGQC8a15XqmVHd5PwoZuCezJDr_j2HG8a7qGF728G0sG8AF6DkgQ=@protonmail.com>
 <CA+kxMuRMXtnqkE1EH4knj=JmyMhKQeWC+rp9=J5nY6bZHs4wLQ@mail.gmail.com>
 <CABdc3WqoSTKKdwzJGjnBETkoHGCMSL4Ri7oN73E0b+by_17zEA@mail.gmail.com> <meh9dlvwyFgnuoN85APPsnXc8Ltyrf0ZRA4T55P9SOsTi9GzCBRFH9meucpRb2Bbh39mWmnqSaLGug2mpFJnGqN23pbdojfJs90y36zSflM=@protonmail.com>
In-Reply-To: <meh9dlvwyFgnuoN85APPsnXc8Ltyrf0ZRA4T55P9SOsTi9GzCBRFH9meucpRb2Bbh39mWmnqSaLGug2mpFJnGqN23pbdojfJs90y36zSflM=@protonmail.com>
Date: Wed, 22 Apr 2020 19:39:05 +0200
Message-ID: <CABdc3Wruc6H+cG1imNPA6eEz32_YjY5wvVDtDMUQwdUR4Zm5hA@mail.gmail.com>
To: moliata <moliata@protonmail.com>
Cc: Dan Ackroyd <Danack@basereality.com>, 
	"internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000082fdc305a3e49cb3"
Subject: Re: [PHP-DEV] Typed callable properties
From: michal.brzuchalski@gmail.com (=?UTF-8?Q?Micha=C5=82_Brzuchalski?=)

--00000000000082fdc305a3e49cb3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Benas,

my responses below.

=C5=9Br., 22 kwi 2020 o 19:17 moliata <moliata@protonmail.com> napisa=C5=82=
(a):

> Hello,
>
> thank you for an opinion as well! While I do fully agree that callable ty=
pe
> 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 specif=
ic
> 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. O=
ne
> 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 woul=
d
> work with "dynamic" callables. For example let's assume we have a framewo=
rk
> that allows registering routes with placeholders to controllers, like thi=
s:
> `$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 functio=
n
> 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=C5=82 Brzuchalski

--00000000000082fdc305a3e49cb3--