reactive-streams/reactive-streams — pull request #25 by benjchristensen (2014-04-15 20:04:52+00:00)
Title: Remove Consumer/Processor/Producer

As per discussions in https://github.com/reactive-streams/reactive-streams/issues/24, https://github.com/reactive-streams/reactive-streams/issues/23, and https://github.com/reactive-streams/reactive-streams/issues/22 I recommend eliminating the `Consumer`, `Processor` and `Producer` types and focusing purely on the interop types.

I spoke with @viktorklang on Skype about this topic and with him decided to submit a pull request to push the conversation forward.

NOTE: This does NOT fix the TCK which will not compile with this change. I want to determine if there is agreement before exerting that effort.

## Why?

#### 1) Simplicity

We should strive for as few types as possible to accomplish the stated goal of library interop. The `Publisher`, `Subscriber` and `Subscription` types achieve this without need for the other 3.

`Publisher`, `Subscriber` and `Subscription` clearly communicate their behavior and relationships via their signatures whereas `Consumer` and `Producer` do not.

#### 2) Not succeeding in hiding SPI

The `Producer` and `Consumer` types are empty synonyms to `Publisher` and `Subscriber` and do not succeed in their effort to "hide" `Publisher` and `Subscriber` from users since Java does not support "friend" style modularity. The types are public and thus accessible. In fact, the `Consumer` and `Producer` types immediately expose the `Publisher` and `Subscriber` types anyways.

#### 3) Focus

This spec should not get involved in how processing pipelines will be established and thus should not have the `Processor` type.

Interop will always occur at explicit boundaries where a library exposes either a `Publisher` or a `Subscriber`. These clearly communicate intent, lifecycle and capability. We do not need further abstraction, indirection, or factory behavior.

#### 4) Safety

The goal of the spec should be to clearly communicate via the types how data flows, not try and prevent users from doing "bad things" through hiding the types. Safety in this case can not be prevented through obfuscation because that just impedes comprehension which in turn is more likely to cause misuse.

Clear, easy to use types are the best strategy for communicating the right mental model which in turn will result in correct usage.