On Thu, Jul 2, 2026, at 2:14 PM, Larry Garfield wrote: > On the question of callable-vs-closure, I agree that today, between FCC > and PFA a Closure is absolutely trivial to produce, so we don't need to > support the variety of legacy callable formats. The one caveat to that > is for compiled code; you cannot store a closure in a serialized form > or in generated code; functions and static methods are easy enough to > store that way (as a string and array, respectively), ugly as those > formats are. Methods, anon functions, etc. however are much harder, > and there's no globally standard way of cheating there. I suspect the > best we can do without scope creeping ourselves to death is just > support closures and leave it to implementers to turn other callable > formats into a closure, which isn't that hard these days.
I just realized one caveat to the above: Invokable objects. There's little point in doing $callableObj(...), other than the implementation of callable objects is kinda screwy right now and isn't part of any type. A callable type definition should support callable objects without forcing the user to squeeze them through closures. --Larry Garfield
