Re: Automatically execute Closures returned from primary script

On Wed, Sep 23, 2026 at 7:44 AM Tim Düsterhus <tim@bastelstu.be> 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.