Re: Automatically execute Closures returned from primary script

On Wed, Sep 23, 2026, at 8:11 AM, Rowan Tommins [IMSoP] wrote: > On 22 September 2026 20:43:11 BST, Seifeddine Gmati > <azjezz@carthage.software> wrote: >>Another approach worth considering is the one used by HHVM/Hack, where >>an entry point is identified using an attribute ... The PHP >>equivalent might look something like this: >> >>```php >>#[EntryPoint] >>function main(): void { >> echo "Hello world!\n"; >>} >>``` > > > I think I like this version better - as well as being more explicit, it > means the entry point doesn't have to be at the very end of the file. > > I don't think I've ever written a file (or wanted to) that was both an > include and an entry point; but I have written files which include both > function and class definitions and code intended for direct execution. > Often, the procedural code is just something like "run_script($argv);" > so adding an attribute would feel natural. I agree with Rowan. I have never, ever needed to do Python-style "library and self-execution" in PHP. The way the language is structured just doesn't make it necessary. And auto-executing a specific return type just feels hacky an unexpected. I'd be -1 on the original proposal here. But I do, typically, have some sort of "get the heck out of the global namespace" function. Automating *that* in a more robust and supported way I could get behind. >>2. Which signatures should be accepted? Possibilities might include >>(), (array $argv), or >>(int $argc, array $argv), with a return >>type of void, int, or >>never. > > > I think this is a good question regardless of the mechanism for marking > the function. One complication would be Levi's suggestion that this > could be useful in web SAPIs as well, where $argv wouldn't mean > anything (and request data is in super-globals). Maybe a specific > #[CliEntryPoint] would provide $argv, and a generic #[EntryPoint] would > not provide anything? Since we have multiple SAPIs, would it make sense to do something like #[EntryPoint('cli')], #[EntryPoint('frankenphp')], etc? With no SAPI name indicating "all", and each SAPI implying a different set of arguments? That might even offer a way to get super-global data passed into a function without referencing the super-globals. (And, crazy crazy thought, a way to register the run function for FrankenPHP worker mode? Dunno if that makes sense, just spitballing.) --Larry Garfield