On Thu, Apr 20, 2023, at 9:47 PM, David Gebler wrote: > On Thu, Apr 20, 2023 at 6:25 PM Larry Garfield <la...@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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
