Deprecate withMonitor or fuse withMonitorRef

[mboes]

I think it's confusing to have both withMonitor and withMonitorRef. The two functions are nearly identical. Could we either deprecate withMonitor, since withMonitorRef is all that's needed, or (at the cost of a breaking change) make the naming consistent with base: i.e.

withMonitor :: ProcessId -> (MonitorRef -> Process a) -> Process a
withMonitor_ :: ProcessId -> Process a -> Process a

(as in mask_ and bracket_ in Control.Exception and elsewhere)

If we deprecate withMonitor now, it leaves us free to recycle that name to make the naming consistent in a later release.

[hyperthunk]

+1

[qnikst]

I agree to make such patch, but I'm not sure what will our strategy be here, and as consequence what to put into deprecation message.

Will DEPRECATED withMonitor "this function is a subject of refactoring in next major release see issue #281 for details" be ok? As it seems that such message will cover all possible cases.

[hyperthunk]

I've deleted my comments/questions about the branching process. We can discuss it on the mailing list instead.

@qnikst that deprecation message looks fine to me.

[qnikst]

@hyperthunk how much effort do you plan to put into d-p now, if there will be enough changes for the major release, we can just remove the message, and write the change to the changelog. If you want to have a minor cleanup release, then deprecation message is fine.

[hyperthunk]

I'm going to pull together a fix for the tracing bugs and a hope to close out a number of other open issues, so let's sit tight until I've got enough changes for a major release.

[qnikst]

Ok, then we should verify that everything is in master and provide deprecation message, will you do that yourself or want me to take care of that.

[hyperthunk]

I'll do it once the rest of my patches have been merged.