Closed rosstuck closed 9 years ago
Also, this is tested with a local dev version of tactician, so this'll fail until Tactician 0.4 is released. I haven't pushed that out yet because it might break folks stuff until we get all the plugins ready to update as well.
Personally I like that interface. It makes a command a command.
However I see the point why the interface could be removed. It could also make handling commands easier in some cases (for example we wouldn't need a QueueableCommand
interface for the Bernard plugin, we can use Bernard\Message
)
But I have to think about this. There are many things to consider.
Yeah, that stdClass thing hurts my eyes. :100: :-1:
As for the release: we agreed that until a major release we depend on MJZ releases in plugins (^0.3 now), so it won't break anything. I think it would be better to release the new version, and update plugins later.
A command stub would be better for this purpose
About the composer version, I bumped it to 0.4 to be more explicit since removing the Command interface means changing the Middleware typehint and thus triggering an error. If someone is running lowest deps or we're testing against them, they'll always break now: this PR makes it completely unable to work with Tactician 0.3, unfortunately.
@sagikazarmark I still need to send a PR for command events or would you rather pick it up? If you'd like me to do it, then let me know how you prefer to setup the stubs (empty interfaces under spec dir, I'm guessing) and I'll pick it up from there.
I don't think backwards incompatibility is a problem now. Tactician and the plugins are not stable yet.
I will handle command events. Thanks.
As per https://github.com/thephpleague/tactician/issues/43 and https://github.com/thephpleague/tactician/issues/45
@sagikazarmark Thoughts? The stdClass mock is a little ugly, could create a specific fixture for it if you prefer.