Subject.toSerialized()

[benjchristensen]

Should we add an instance method such as:

class Subject<T, R> {
   public SerializedSubject<T, R> toSerialized()
}

Currently the way to get a SerializedSubject is via the constructor:

new SerializedSubject<T, R>(subject);

Related to addition of SerializedSubject in #1744

[headinthebox]

It is sad that Java has no extensions methods.
Howevere it is a bit weird since (Imassume) serialized subject is also a subject, so we can call xs.toSerialized().....toSerialized()

I vote to keep things as is for now.

[benjchristensen]

Moving to 1.0 as this is easy to add.

[samuelgruetter]

I agree with @headinthebox that xs.toSerialized().....toSerialized() looks a bit weird at first sight, but if the semantics of toSerialized are "make sure that it's a serialized subject" instead of "wrap the subject in a serialized subject", it makes sense. That is, the default implementation in Subject would be to return a new SerializedSubject, and SerializedSubject would override it and just return this. This would also be extensible, because users could add a MyOwnSerializedSubject, which does not extend SerializedSubject, but only Subject, and also returns this in the toSerialized method.

[benjchristensen]

we can call xs.toSerialized().....toSerialized()

I can do that on an Observable as well.... observable.serialize().serialize().serialize()

if the semantics of toSerialized are "make sure that it's a serialized subject"

Yes it can check that is in an instance of the already wrapped Subject and not wrap again.

[benjchristensen]

The signature could be:

public SerializedSubject<T, R> toSerialized();

This way it is clear what is being returned.

[zsxwing]

public SerializedSubject<T, R> toSerialized();

If using this one, the case mentioned by @samuelgruetter cannot work.

This would also be extensible, because users could add a MyOwnSerializedSubject, which does not extend SerializedSubject, but only Subject, and also returns this in the toSerialized method.

[samuelgruetter]

We could make an abstract SerializedSubject class which is just for labelling, and rx would provide a default implementation.

[headinthebox]

Sounds good.

[benjchristensen]

I added toSerialized. I did not make SerializedSubject an interface because it follows the same pattern as SerializedObserver and SerializedSubscriber. The "serialized" part IS the implementation of the Subject.

Even if we were to make SerializedSubject into an interface we'd also need to make SerializedObserver and SerializedSubscriber into interfaces.

Also, there are really only 3 ways to approach this that I'm aware of:

• Using blocking synchronization. We are trying to avoid that. We used to have SynchronizedObserver and replaced it with SerializedObserver.
• Using queues and thread-stealing to push through. This is the model SerializedObserver and SerializedSubject use.
• Using an MPSC queue with a separate thread to drain (standard producer/consumer). We don't want to add extra concurrency so are avoiding that. If an extra thread is wanted then observeOn is the answer.

Thus, there is really only one approach we want for this, and that is the SerializedObserver approach, hence SerializedSubject, which is an implementation of Subject that adds the Serialized capability.