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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
