On Wed, Sep 23, 2026, at 8:11 AM, Rowan Tommins [IMSoP] wrote:
> On 22 September 2026 20:43:11 BST, Seifeddine Gmati
> <[email protected]> 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