Re: [RFC] Configurable callback to dump results of expressions in `php -a`

Hi Rowan Tommins, > > - The benefit is that dumping the result of expressions improves the default experience. > >    psysh wouldn't be installed by default when a new developer is learning php > >through the php manual, or when sshed into a remote server. > > It doesn't feel to me that you've really answered Nikita's question: if > all the code using these hooks is going to be distributed as userland > code anyway, then they're not going to improve the default experience. I was saying that I'd planned to propose defaults if this passed. __debugInfo() is a slight improvement, but the human-readable representation of an object isn't always the same thing as the debug representation of the object. A human-readable representation might be Point(x: 1, y: 2), where var_dump or var_export(__set_state) is much longer, and I don't believe var_dump is a one size fits all solution for both simple and recursive data structures, especially since __debugInfo predates the repl. ``` php > class Point { public function __construct(public int $x, public int $y) {} } php > var_export(new Point(1, 2)); Point::__set_state(array( 'x' => 1, 'y' => 2, )) ``` > It feels like we need to go in one of two directions: > a) Build a full-featured official REPL with all of these improvements > completely implemented out of the box. Limited extension hooks might > still be desirable to build custom versions for frameworks etc, but they > could be more targeted - for custom input, it could be "register > meta-command"; for custom output, we already have __debugInfo() at the > class level. I'd be happy as long as we made progress on improving the interactive shell.. Psysh is 2.4MB as a compiled phar release and larger if distributed with library/application releases (e.g. on remote servers). default extension hooks would likely be much smaller. > b) Expose the magic behaviour needed for something like PsySh to do > everything php -a already can, and leave the rest to userland. > So far, > the only mentioned requirement is a special form of eval() that swallows > fatal errors. That may or may not be possible to do through creating a new unsafe_eval PECL (or only exposing it for interactive sessions) - I'd have to check. Something like unsafe_eval(string $code, array &$variables): mixed result (or throw UnsafeFatalError) The usual caveats about not using it in production would apply - the php compiler treats eval differently in that it has access to the caller's scope. https://github.com/bobthecow/psysh/blob/master/src/ExecutionLoopClosure.php uses eval(), but there's actually a lot of heuristics to avoid calling eval() on code with common known fatal errors. (it uses the readline/libedit PHP module if it's available, but doesn't load readline_cli.c) The ext/readline/readline_cli.c overrides EG(bailout) with zend_try macros to recover from fatal errors ```c zend_try { zend_eval_stringl(code, prompt_end - prompt_spec - 1, NULL, "php prompt code"); } zend_end_try(); ``` > My feeling is that the current mood of the community favours (b) rather > than (a); the most obvious example is that PHP used to bundle a PEAR > executable, but Composer remains an entirely external project. Is there > a reason not to aim for the same "de facto standard" for a REPL? Even if we do start distributing a better alternative shell with php or endorsing an alternative in docs, it's still possible to incrementally improve php -a It seems like a significant missing feature to omit printing expression results from php -a; people who do use php -a may wish to continue using that feature set (e.g. #setting_name=value to set/dump ini variables) but still benefit from minor improvements such as this RFC. https://github.com/bobthecow/psysh/issues/462 mentions psysh isn't a drop-in replacement. E.g. on shared hosting or when debugging on a remote host, it may be inconvenient to download psysh and faster to use php -a https://www.php.net/manual/en/features.commandline.interactive.php only mentions php -a. Perhaps it should mention external userland shells with a note that they're developed independently if the REPL rarely receives updates in favor of other functionality. - Someone learning from the php.net manual or a tutorial with minimal dependencies wouldn't install psysh right now. Aside: the php manual doesn't mention composer except in a few PECL extension docs, but people seem to figure out how to use composer out of necessity and library installation docs. Interactive shells wouldn't be as advertised Cheers, -Tyson