Should IReceivableSourceBlock and ISourceBlock be merged?

Question

The "Introduction to TPL Dataflow" (April 2011) document states that ISourceBlock has TryReceive and TryReceiveAll methods, which it does not.

These are of course part of IReceivableSourceBlock.

However, I wonder should these two interfaces be merged, so that we have an ISourceBlock that looks the way it is stated in that document (and get rid of IReceivableSourceBlock). It would (literally) simplify the picture, with one base interface (IDataflowBlock), an interface each for source and target, and finally an interface for both (IPropagatorBlock).

I note each block implementation in TPL Dataflow that implements ISourceBlock also implements IReceivableSourceBlock, so that the actual implementations need not change.

Eamon O'Tuathail 

Answer 1

Hi Eamon-

Thanks for the suggestion!  These interfaces were actually originally just combined into ISourceBlock (and if the Introduction to TPL Dataflow document still states that, we'll need to fix it, thanks for letting us know).  They were separated out, however, primarily to enable ISourceBlock to be covariant, which couldn't be done with the signatures now in IReceivableSourceBlock. There are also some cases where it's nice not to have to implement the receive methods on IReceivableSourceBlock, and in fact some of the blocks we use internally don't.