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
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:
-
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. -
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. -
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