PostRun Done Hook

[sarelvdwalt]

It would be cool to have a function that the BaseCommand will always call via it's destructor - as the first act. This can be used to say "hey, will you please SMS me when you're done?"

We can later on build some strategies around this, so we can call our commands with something like:
--done-sms=0821231234
--done-email=sarel@example.com
--done-task-complete

[mostertb]

This is an interesting idea that has a lot of application. I like it

Here are some general thoughts:

1. The actual logic that is needed to be run at the end of the execution is highly domain specific to particular users. To overcome this, we should probably look at a strategy pattern (as you've hinted at) with the concrete strategies implementing some 'done / notification' interface rather than just a function and execution parameters. We could then implement some basic concrete strategies (such as calling a URL endpoint ) but allow users to specify their own class that implements the interface to be instantiated and run. An example where this could be useful might be if the completion notification needs to go on to some in-house queueing system for example.
2. It would be valuable for such a feature to be able to distinguish between successful completion and failures so that different logic can be run (or in your example of notification, the success or failure can be notified). In order to get this information, the destruction may not be the correct place for this. Have a look at \Symfony\Component\Console\Command\Command::run for some ideas other places to hook in to
3. Destructors have some other concerns:
   • Error handling is challenging. If you throw an exception in a destructor, PHP fatal errors
   • The destructor is only called when the last reference to the object goes out of scope (and garbage collection subsequently gets the object). This means that if a memory leak is accidentally introduced to the Symfony framework, we may end up with undefined behaviour.
4. We are essentially providing a completion hook. We should decide if this is specifically for notifications or if any logic can be hooked here. This will help guide the feature. Once we've done this, we need to be careful that we don't cannibalize other features mistakenly. An example is doing failure notifications via logging with Monolog's FingersCrossedHandler instead
5. A separate feature that would help support you end example is a way for such strategies to add their own parameters. I'll probably flesh this out a little

[mostertb]

I've given this some thought. I'll implement this feature