Re: [Discussion] Callable types via Interfaces

From: Date: Thu, 20 Apr 2023 21:52:03 +0000
Subject: Re: [Discussion] Callable types via Interfaces
References: 1 2  Groups: php.internals 
Request: Send a blank email to internals+get-120092@lists.php.net to get a copy of this message
On Thu, Apr 20, 2023, at 9:47 PM, David Gebler wrote: > On Thu, Apr 20, 2023 at 6:25 PM Larry Garfield <larry@garfieldtech.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 the >> most support is the purpose of this thread. >> > > My initial feelings based on the options laid out is that anything which > can't support FCCs in the manner of strlen(...) is probably a non-starter > 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 engine > (correct me if I'm wrong?) and probably the best syntax for the user within > the interface approach. But then do we really want to introduce new runtime > 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 to implement, and have the largest performance risk, but be the nicest/most 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? It'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

« previous php.internals (#120092) next »