> like a generic CommandBus rather than a CLI specific one
Please, don't mix up things. CommandBus has nothing to do with CLI Command. 

CLI Command is just UI detail exactly like HTTP controllers.
They are not place for business logic.
This problem is already known as 
https://en.wikipedia.org/wiki/Magic_pushbutton anti-pattern.
Thus, it's better to ask sane API (decoupled from UI) from mentioned 
vendors (Doctrine and others) in order to make things
instead of asking abstract CLI commands.

On Thursday, July 7, 2016 at 3:58:40 PM UTC+3, Stefano Torresi wrote:
>
> 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/dcebf668-78f8-45a5-a71d-859fe2a01f8f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to