Consumer.getSubscriber?

[benjchristensen]

If Subscriber is considered part of the SPI and never intended for use by the user, why is it exposed on Consumer?

public Subscriber<T> getSubscriber();

In particular, what would be the point of ever retrieving it? There are no methods of use to invoke from a consumer perspective. In fact, if any are invoked they are now altering the data flow.

The javadoc states "This method should only be used by implementations of this API."

Since an implementation would have access to the concrete types and capable of getting this anyways it seems that it should not be on the Consumer type where it will confuse and allow incorrect behavior.

[rkuhn]

When saying “capable of getting this anyways” you imply that each implementation knows about the other in order to interface. Taking an Rx Producer and an Akka Consumer as an example, how would you implement produceTo without having access to the getSubscriber method? Keep in mind that the Consumer and the Subscriber are not necessarily the same object.

This question and some of the others you raised tell me that the intention of the API might not be entirely clear yet: the Producer/Processor/Consumer types are not meant to be the user-facing API, they are meant to be only those elements of the API which allow interoperability of different implementations of the SPI.

In Rx when you get an Observable you know what that is quite precisely. When you get a Producer as per this spec, you don’t know which implementation it has.

[viktorklang]

Also note that this is Java (JDK) convention (probably due to the fact that Java's access rules are quite limited (no friend access etc): http://docs.oracle.com/javase/7/docs/api/java/nio/channels/SelectableChannel.html#provider()

[benjchristensen]

how would you implement produceTo without having access to the getSubscriber method?

That's exactly my point. The API does not hide the SPI, it just provides accessors to it.

the Producer/Processor/Consumer types are not meant to be the user-facing API, they are meant to be only those elements of the API which allow interoperability of different implementations of the SPI.

Agreed, and since the purpose is just for interoperability, let's just use Publisher/Subscriber directly. They are clear and communicate the contract.

When interop between libraries happens it's always going to be explicit bridging between them, so let the types clearly communicate where that happens. How does returning a Producer provide a better approach when it's just an indirection to getting Publisher?

For example, in Rx we could have something like this:

class Observable {
   public Publisher toPublisher();
}

or

class Observable implements Producer<T> {
   public void produceTo(Consumer<T> consumer);
   public Publisher<T> getPublisher();
}

In either case, a user needs to know the Observable class has a hook to become a Publisher. Why not just let the user invoke Observable.toPublisher() when passing to a separate library rather than relying on the Producer.getPublisher and Producer.produceTo interfaces? This way it keeps the types simple and clear.

The first example above is clear and can't be mistaken. The second one is troublesome because what Consumer implementations can it handle? In reality, it can only handle the RxJava Consumer implementation, and since we're in the RxJava library we don't need that and will never use it.

If I were to pass the RxJava Observable implements Producer to Akka, all Akka could do is call getPublisher. It will completely ignore produceTo as it will know nothing of Akka.

AkkaPublisher.from(RxObservable.toPublisher()).subscribe(anAkkaSubscriber)
// or
RxObservable.toPublisher().subscribe(anAkkaSubscriber)

Thus, I don't see how produceTo is of any value at all which leaves getPublisher. At that point, why bother having the indirection, just let a library expose Publisher directly instead of via Producer.

Also note that this is Java (JDK) convention

The JDK doing something a certain way is not necessarily a good reason for us doing the same. Especially the NIO API which is basically unusable by anyone without further abstractions on top of it.

As a side note, libraries that have a "zero dependency" policy such as RxJava (and I imagine Netty based on www.netty.io homepage statements?) are not going to become dependent on these types in their core libraries until Java 9 or whatever has these. This means that the RxJava Observable is not going to have either solution above. It will be a submodule that adds that dependency and would be something like a ReactiveStreamsPublisher that bridges the APIs.

[smaldini]

Btw stupid but why not: getting rid of getXX and just use plain publisher()/subscriber() ?

Sent from my iPhone

On 15 Apr 2014, at 13:09, Viktor Klang (√) [email protected] wrote:

Also note that this is Java (JDK) convention (probably due to the fact that Java's access rules are quite limited (no friend access etc): http://docs.oracle.com/javase/7/docs/api/java/nio/channels/SelectableChannel.html#provider()

—
Reply to this email directly or view it on GitHub.

[normanmaurer]

I guess get* is more java like ? Not that I would dislike removing them ;)

-- 
Norman Maurer

Am 15. April 2014 bei 19:10:07, Stephane Maldini ([email protected]) schrieb:

Btw stupid but why not: getting rid of getXX and just use plain publisher()/subscriber() ?

Sent from my iPhone

On 15 Apr 2014, at 13:09, Viktor Klang (√) [email protected] wrote:

Also note that this is Java (JDK) convention (probably due to the fact that Java's access rules are quite limited (no friend access etc): http://docs.oracle.com/javase/7/docs/api/java/nio/channels/SelectableChannel.html#provider()

—
Reply to this email directly or view it on GitHub.
—
Reply to this email directly or view it on GitHub.

[smaldini]

Well these java beans semantics are just outdated, plus getter on an interface looks awkward. I'm just thinking loud, in the end we have in Reactor a few place where a Consumer also implements a subscriber and getSubcriber returns this.

Sent from my iPhone

On 15 Apr 2014, at 18:20, Norman Maurer [email protected] wrote:

I guess get* is more java like ? Not that I would dislike removing them ;)

Norman Maurer

Am 15. April 2014 bei 19:10:07, Stephane Maldini ([email protected]) schrieb:

Btw stupid but why not: getting rid of getXX and just use plain publisher()/subscriber() ?

Sent from my iPhone

On 15 Apr 2014, at 13:09, Viktor Klang (√) [email protected] wrote:

Also note that this is Java (JDK) convention (probably due to the fact that Java's access rules are quite limited (no friend access etc): http://docs.oracle.com/javase/7/docs/api/java/nio/channels/SelectableChannel.html#provider()

—
Reply to this email directly or view it on GitHub.
—
Reply to this email directly or view it on GitHub.
—
Reply to this email directly or view it on GitHub.

[jbrisbin]

I agree with Stephane. We've had this argument internally over whether it's appropriate to have getters and setters declared in interfaces and our general consensus is that, although there's not inherently "wrong" with it, it often indicates a problem with the API.

[viktorklang]

@jbrisbin A problem as in "don't have methods that take no parameters and return some value" or a problem as in "don't name that kind of methods getX"? (personally I don't care, it seems to be The Java Way)

[smaldini]

sorry miss click - dat button close just left comment... -

[viktorklang]

@smaldini Yeah, it's super nice placement of buttons ;)

[rkuhn]

I think we can close this and discuss on the pull request?

[smaldini]

Agree, closing it since I am good at it (anyone can reopen if it feels necessary).