Ah got it, thanks for pointing out the 8.7 timeline Larry.
On the PECL to core transition, I personally lean toward sooner if people see value in it, mostly so internals can help shape the API early before conventions get locked in userland. For anyone curious to test or poke around the code, the repository is here: https://github.com/prateekbhujel/php-terminal
Any PRs, feedback, or design critiques are more than welcome.
Curious what you and others think on whether this makes sense as an RFC direction for 8.7, or if there are particular areas you would want adjusted first?
Pratik
Hi
On 2026-09-17 17:30, Pratik Bhujel wrote:
Curious what you and others think on whether this makes sense as an RFC
direction for 8.7, or if there are particular areas you would want adjusted
first?
I don't understand much about the problem you're tackling, so I can't meaningfully comment on if the API makes sense on a "high level" domain specific perspective. However for the API to become a first class citizen some changes will need to be made:
1. With the new polling API introducing the Io namespace, the functionality should likely be provided as Io\Terminal. Grouping it under Io makes sense to me and avoids reserving another top-level name.
2. Classes are not namespaces: Static methods that are not named constructors should be free-standing functions. Thus Io\Terminal\enable_ansi(), Io\Terminal\set_title(), etc. Alternatively since they almost all seem to take the "file descriptor" as the first argument, they could also be instance methods on an Io\Terminal\Terminal class that receives the terminal handle in the constructor. I leave it up to the domain experts to decide what makes more sense.
3. The enums should be unbacked. A backed enum is almost always the wrong design decision, since there is rarely a single canonical and obviously correct scalar representation.
Best regards
Tim Düsterhus