Automatically execute Closures returned from primary script View as Markdown

Hi

Just to confirm my understanding: when the file is included from
another script, the closure would still be returned without being
executed,
so the following would continue to work as it does today:

$callable = require 'script_file.php';
$callable();

Is that correct?

Yes. The only change is that the PHP CLI SAPI will make use of the
return value of the main script rather than ignoring it. No changes for
any other SAPI and no changes to include/require. Please see the
tests in the PR, and in particular
sapi/cli/tests/primary_script_closure_004.phpt.

Best regards
Tim Düsterhus

Hi Tim,

That makes sense, thanks.

Another approach worth considering is the one used by HHVM/Hack, where
an entry point is identified using an attribute:

<<__EntryPoint>>
function main(): void {
    echo "Hello world!\n";
}

The only documentation reference I could find is here:
https://docs.hhvm.com/hack/contributing/code-samples/#basic-usage

Hack prefixes built-in and special attributes with __. The PHP
equivalent might look something like this:

#[EntryPoint]
function main(): void {
    echo "Hello world!\n";
}

A function carrying this attribute in the main script would be
executed automatically. This makes the entry point explicit and avoids
assigning special meaning to the script's return value.

There would be a few semantic questions to resolve:

1. Should top-level code in the main script execute before the
   entry-point function?
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.
3. What should happen if multiple functions are marked as entry
   points? A compile-time error seems reasonable.

I still like the returned-closure proposal, but I think this
alternative is worth considering.

Best regards,
Seifeddine

Hi

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.