Re: [RFC] Io\Terminal

From: Date: Fri, 02 Oct 2026 15:59:28 +0000
Subject: Re: [RFC] Io\Terminal
References: 1 2 3 4 5 6 7  Groups: php.internals 
Request: Send a blank email to internals+get-132772@lists.php.net to get a copy of this message
Hi On 2026-10-02 16:19, Larry Garfield wrote:
My main concern is being able to mock the terminal in order to effectively test code that uses the terminal, without putting a proprietary thin wrapper around it (which largely defeats the purpose of having a good API in core).
It is not clear to me what you mean by “proprietary” here. As I had mentioned in my email, the RFC’s own PR is tested against processes spawned using proc_open() with pty descriptors. The tests are naturally BSD-licensed, just like PHP itself is (since PHP 8.6). In your test you would create a process that emits scripted output (possibly in response to some input), just like you would in the “mocked interface implementation” and then pass the PTY input/output streams to whatever you want to test, which will then call (System)Terminal::fromStreams() using them as parameters. The logic under test reads inputs from the Terminal instance and writes output using fwrite(). The subprocess will also enable you to properly model concurrency, delay and timing in IO processing. Terminal interactions in the real world are not synchronous either: The terminal logic relies on timing to distinguish escape sequences from individual characters (that's what the $sequenceTimeout is for) and the user might already provide additional input while your application is still busy rendering output and not yet expecting additional data.
Interfaces are the standard way of doing that. If you have a suggestion for a better way, I'm happy to see it.
My email included 5 arguments as to why an interface is the wrong design here. Do you plan to engage with those? Best regards Tim Düsterhus

« previous php.internals (#132772) next »