Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:120092
Feedback-ID: i8414410d:Fastmail
User-Agent: Cyrus-JMAP/3.9.0-alpha0-372-g43825cb665-fm-20230411.003-g43825cb6
Mime-Version: 1.0
Message-ID: <704fdff6-77b0-48b2-a095-c04c1de381a4@app.fastmail.com>
In-Reply-To: 
 <CA+p1Faat2-Ze7HzLJaeKtmQ1kRqdDUqTzVoA2KHLPuh0_Yz=0Q@mail.gmail.com>
References: <6b5de716-d769-4f0b-b3e6-5a5a211f035a@app.fastmail.com>
 <CA+p1Faat2-Ze7HzLJaeKtmQ1kRqdDUqTzVoA2KHLPuh0_Yz=0Q@mail.gmail.com>
Date: Thu, 20 Apr 2023 21:52:03 +0000
To: "php internals" <internals@lists.php.net>
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [Discussion] Callable types via Interfaces
From: larry@garfieldtech.com ("Larry Garfield")

On Thu, Apr 20, 2023, at 9:47 PM, David Gebler wrote:
> On Thu, Apr 20, 2023 at 6:25=E2=80=AFPM Larry Garfield <larry@garfield=
tech.com>
> wrote:
>
>> ## The options
>>
>> There's three ways we've come up with that this design could be
>> implemented.  In concept they're not mutually exclusive, so we could =
do
>> one, two, or three of these.  Figuring out which approach would get t=
he
>> most support is the purpose of this thread.
>>
>
> My initial feelings based on the options laid out is that anything whi=
ch
> can't support FCCs in the manner of strlen(...) is probably a non-star=
ter
> in terms of language design. Changes like this are fundamentally about
> making things simpler, more concise and more convenient for users, not
> drip-feeding a stream of "and here's yet another way of working with..=
."
> features across releases.
>
> Structural typing option seems like the easiest to implement in the en=
gine
> (correct me if I'm wrong?) and probably the best syntax for the user w=
ithin
> the interface approach. But then do we really want to introduce new ru=
ntime
> checks and complexity when the general trend of the language has been =
in
> the opposite direction? I imagine probably not.

Our assumption is the opposite: Structural typing would be the hardest t=
o implement, and have the largest performance risk, but be the nicest/mo=
st convenient for developers.

> So out of the three, I lean towards adding castTo() to Closure and it =
maybe
> raises a to-be-determined Throwable if the closure is already bound? I=
t's
> not as friendly for the user as the other options but it seems like the
> most workable, it delivers value and it most closely fits within the
> existing way of working with all types of closure today.
>
> -Dave

--Larry Garfield