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

Reply via email to