Re: Re: [PHP DEV] [Discussion] Native terminal helpers for PHP CLI

Hi On 9/26/26 13:26, Pratik Bhujel wrote:

I made the changes from your review in 0.9.0: a unified Terminal session, create/from constructors, an OO-only API, and TerminalSize instead of separate width/height helpers. 1.0.0 then froze that session API as the stable 1.x contract. 1.1.0 added readEvent after working through what Symfony TUI actually needs; readKey is useful for normalized keys, but TUI also needs raw POSIX chunks and native Windows event details.

Thank you. I have taken another look at the API: 1. The timeouts should be specified as Time\Duration objects (which was added specifically to PHP 8.6 for this kind of purpose; take a look at Io\Poll for an example). 2. Is Terminal::__construct() identical to Terminal::fromStreams()? Generally when you have named constructors, you shouldn't also offer a regular constructor.

Symfony Console/TUI PR #66173 is now using ext-terminal optionally for terminal size, hidden input and raw mode: https://github.com/symfony/symfony/pull/66173 Nicolas Grekas has approved it, and GromNaN also approved it after testing and benchmarking the native size path on macOS. That integration work has been useful because it exposed real compatibility and behavior questions rather than only API design in isolation.

That is great and inspires additional confidence that the API design is right.

At this point I do not think the RFC should simply move the extension into core unchanged. My current thought is a smaller Io\Terminal surface for PHP 8.7, with the extension remaining useful as the reference implementation and backport, and compatibility-only pieces left out of the core proposal.

Yes, the compatibility-only parts should not be included in PHP itself.

Before I write the formal RFC, I would like to sanity-check that direction here. Would you prefer the initial RFC to stay with the higher-level primitives such as session creation, TTY/size, raw mode, hidden input and readKey, or does including the lower-level readEvent primitive also make sense given the Symfony TUI use case? Again, not an expert on the domain, but I think including everything that is useful and where we are confident it won't need any further changes makes sense to me.

Best regards Tim Düsterhus