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
