On Wed, Sep 23, 2026 at 7:44 AM Tim Düsterhus <[email protected]> wrote:
>
> Hi
>
> On 2026-09-22 23:12, Levi Morrison wrote:
> >> this thread concerns my PR carrying the same title as this email:
> >> https://github.com/php/php-src/pull/23658, where Gina requested that I
> >> ask the mailing list for opinions and/or objections against the
> >> feature.
> >
> > Why is this PR scoped to the CLI SAPI? Shouldn't it apply equally to
> > any SAPI's top-level script?
>
> The “file is both a library and executable” use case is only really a
> thing for a single-file deployment, because otherwise you could just
> separate the executable bit into a different file. I believe that making
> a library do something useful when executed directly is something that
> would work for the CLI SAPI. In web contexts, where the front-controller
> pattern is already well-established and where you generally have an
> allow-list of legal entrypoints (mostly just your front-controller) for
> security reasons I don't see it working well.
>
> Best regards
> Tim Düsterhus
Perhaps you have not seen this pattern in Symfony:
```
require_once dirname(__DIR__).'/vendor/autoload_runtime.php';
return function (array $context) {
return new Kernel($context['APP_ENV'], (bool) $context['APP_DEBUG']);
};
```
It uses (in my opinion) horrible autoloader magic to re-include the
file to make it work. But nonetheless, this is partly why I asked why
you scoped it to just CLI.
I don't really like top-level code, so in some respects it might be
nice to have an annotation for some function to be called
automatically. But I would need to think about this more if I would
actually support such a proposal, as I don't particularly like
annotations either. Perhaps status quo is better.
