Eager usage of eval makes PsySH having fatal errors with valid PHP code

[castarco]

Trying to define a class in a conditional way, PsySH shows to me a FATAL error, but this is correct PHP code.

If y try to execute the same code with the PHP interpreter, then I haven't problems

<?php

$a = 3;
if ($a > 2) {
    class A { public $p=5; }
} else {
    class A { public $p=7; }
}

$a = new A();
echo $a->p . "\n";

This snippet prints

5

[bobthecow]

That's not due to eager use of eval, that's because PsySH is trying to save you from yourself. It's a fake fatal error (you can tell the difference because real fatal errors are white text on black, and will exit to the terminal if you're on Windows). This particular fake fatal error is trying to save you from something like this:

class A {} class A {}

Figuring out whether user input is like yours, which is okay, or like mine, which will fatal error, is most likely equivalent to the halting problem, so we won't ever solve it :)

So the real question is, which is more important? Keeping you from redefining a class (/interface/trait/etc) in the same (e.g. copy pasted) input, or letting you conditionally define the same class? PsySH usually errs on the side of letting you do anything that's valid, and trying to protect you from as many invalid things as possible, but in this case I don't have a strong opinion.

[castarco]

I'm not sure what's convenient. Redefining two times the same class in the same command is clearly wrong and the intuition says me that the user should be protected from doing it. But, your comment has made me think and I've done an experiment:

PsySH doesn't let me to redefine the class, even if I'm in an interactive session which exists mainly for experimentation (the code that I write to the console isn't for production environments).

I don't know which are the associated problems of letting the users to redefine classes in interactive sessions, I'm sure there are a lot of problems, but I think it's worth to capture in a public text why it's preferable one option over another option.

[Markcial]

He really made a good statement there, so +1 about this.

Maybe a option or parameter that sets the session as interactive and make that session able to set unset classes declarations. I know it will be tricky and complicated, but maybe it would be a nice feature for a testing environment not production related

[bobthecow]

IIRC, many moons ago, @nateabele started working on a runkit extension for psysh. That'd probably be the best way for something like this to work. Maybe a handful of commands to undefine or rename classes, methods, etc?

[nateabele]

Yeah: https://github.com/bobthecow/psysh/tree/runkit

I'll poke around and make sure that's up-to-date with my local. It still has a number of issues that need to be worked out, not the least of which is that runkit is not exactly, completely... uh, maintained.

[bobthecow]

Is there something else we can use besides runkit to allow meddling with things that PHP doesn't like you meddling with?

[nateabele]

This seems promising: https://github.com/krakjoe/uopz

The following opcodes can be overloaded by uopz:
[...]

• ZEND_FETCH_CLASS

[nateabele]

Okay, I rebased my local changes and pushed to the branch, in case someone wants to use it as a point of reference. The rebase was a little hairy, so at least one thing is probably rong.

[bobthecow]

…so at least one thing is probably rong.

Please tell me you spelled “wrong” wrong on purpose ;)

[nateabele]

😉

[bobthecow]

The initial bug report was fixed by 0b78bf2

The "code reloading" request was fixed for PHP 5.x with the runkit extension. There doesn't seem to be any progress on a similar extension for PHP 7.x. Additionally, that request is covered by #416 so I'm closing this one.