> Reading through the linked earlier mail, you have quite a few additional > hooks in mind, which might need a significant amount of additional userland > code (such as a parser implementation) to usefully implement. At that point > I'm wondering what the benefit of this hybrid approach is, relatively to a > userland implementation like psysh. > > That is: > a) Assuming all the hooks have been implemented, what additional > functionality is the interactive shell implementation itself actually > providing? > b) Is it possible to go the other way around, and expose that additional > functionality to userland instead? You do mention fatal error tolerance as > one distinguishing feature -- is there anything beyond that?
For https://wiki.php.net/rfc/readline_interactive_shell_result_function in particular, compared to `php -a` in php 8.0, a subsequent RFC would provide additional functionality using these hooks: it would add default hooks to print a short representation of results of expressions to the interactive shell implementation (that could be turned off or replaced to dump objects) - 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. - The reason to allow hooking it is because some objects wouldn't have a user-friendly representation for var_dump/var_export (e.g. recursive data structures) - Even if the code size is large, it may be doable by making the userland implementation part of ext/phpi/ (--enable-phpi), which is disabled by default and can be installed in separate packages created by operating system package maintainers (and shrunk by using minifiers) Compared to psysh, the main distinguishing feature is definitely the ability to detect/tolerate fatal errors when compiling snippets or inheriting classes, and fewer dependencies to include to integrate an interactive shell with utilities for a project. I don't think it should be exposed to regular processes or web servers, though, due to possible memory corruption or leaks after zend_error_noreturn (e.g. class inheritance errors after autoloading), etc.). - It would possibly be an improvement to throw an error instead of causing a fatal error for common mistakes in interactive shell sessions such as duplicate functions/parameters but I'm not sure how likely that is, especially since classes and functions currently get added as the file is being compiled. Integrating userland shells like `psysh` deeply into `php -a` may wish to avoid readline entirely and call a callback instead of printing `php>` and directly processing input like those projects already do. Two hooks may help with enabling that approach, which can be added in `auto_prepend_file` 1. A hook to call a callback instead of printing "php >" and C readline reading stdin. e.g. `readline_replace_interactive_shell_initializer(function () { ... read and process stdin in a loop })` 2. Adding a hook to call a function every time an uncatchable fatal error was encountered, e.g. to resume the userland shell. e.g. `readline_replace_interactive_fatal_error_handler(function ($errcode, $errmsg, $file, $line, $errcount): bool { /* process or exit */ })` Thanks, - Tyson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
