Re: Automatically execute Closures returned from primary script
| From: | Rowan Tommins [IMSoP] | Date: | Wed, 23 Sep 2026 13:11:02 +0000 |
| Subject: | Re: Automatically execute Closures returned from primary script | ||
| References: | 1 2 3 4 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-132602@lists.php.net to get a copy of this message | ||
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.
>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?
Rowan Tommins
[IMSoP]