I think starting with just a Command interface would be best, and possibly leaving the executor to a different PSR (or even multiple PSRs, like a generic CommandBus rather than a CLI specific one).
The main use case is that there are already plenty of vendor specific implementations and adapters in the wild. I don't agree with Andrew's point about limiting innovation. I reckon commands are much simpler to model than HTTP messages; the API would be minimal, so it shouldn't impose relevant limitations to implementors. I'm not even sure what is left to innovate in CLI applications, as they've always been pretty much the same since the dawn of shells: invoke by name, may accept input (arguments and/or stream), may provide output, will provide an exit code. Am I missing anything? Furthermore, at end of the day its always a Recommendation; nothing prevents anyone from doing their own thing. For example, Python has a comprehensive standard library for everything Andrew mentioned (stdin, stdout, stderr, argc, argc, cwd), with multiple builtin modules around the same details (e.g. getopts and argparse). Has that prevented any innovation in Python CLI applications? Nope, I'm sure there some exotic packages to parse CLI arguments in PyPI. And we're not even proposing implementations here. -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAFojS1v2SC%2B_WoxYDSPGtAP56se3YvpG8094EQCCs3Sw%3DKDeiA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
