2.12 Clarify "object equality"

[anthonyvdotbe]

Rule 2.12 mentions "based on object equality". Is this meant to be as in "a == b" or as in "a.equals(b)"?
I believe the semantics ought to be as in "a == b", and thus the wording "based on object identity" would be clearer. In case of the latter, "based on Object::equals" would be better, in my opinion.

In my opinion, it would be worthwhile to update rule 1.10 accordingly by clarifying "different", for example:
Publisher.subscribe MAY be called as many times as wanted but MUST be with a different (based on object identity) Subscriber each time [see 2.12].

[akarnokd]

Rule 2.12 is strange because it implies each Processor must track and remember every Subscriber it saw, causing more memory use and retention. We have a few cases where a completely safe Subscriber can handle any number of (non concurrent) onSubscribe calls during its lifetime. If we'd obey this rule, that requires a meaningless instantiation of the same Subscriber just to satisfy the equality check. See #290. Same view applies to the dual rule of 1.10.

We talking about this with @smaldini and we think both rules should be weakened in the next update by saying if you want Subscriber reuse, you are on your own and consider all possible call patterns. In this case, object equality or identity doesn't mean anything anymore.

[DougLea]

Requiring "equals" was just to accommodate the use of proxies and the like. I don't think changing it will much affect #290.

[viktorklang]

From a garbage-tracking perspective, mandating that Publisher keep a history of all Subscribers they've seen is unreasonable. However, if a Publisher keeps track of its current Subscribers, it should also be responsible and prevent double-subscriptions, to be a good citizen. Does that make sense?

As for object equality, it is strictly preferable over instance equality from a wrapper/delegate/proxy PoV.

[anthonyvdotbe]

Thanks for mentioning the case of proxies etc., makes sense to me.

I believe it would be useful to add this as a footnote to the specification, exactly as @viktorklang said:
[2] object equality is strictly preferable over instance equality from a wrapper/decorator/proxy point of view

What do you think?

[viktorklang]

@anthonyvdotbe I've been meaning to affix a "Rationale"/"Intent" to each of the spec rules to provide more background. Hopefully I'll have time to start doing that soon, it'll need to get vetted by the SIG but it should be massively beneficial to readers.

[smaldini]

BTW we do suffer the issue in a tck doing reference equality check for errors. It prevents any sort of error proxy/serialization/decorator.

Another test related to this is the Subscriber dereferencing test which should be updated accordingly to support immutable publisher/subscriber relationship (and dereferenced once publisher and subscriber have both dereferenced, currently the tck is holding the publisher reference).

[viktorklang]

@smaldini

Hmmm, what do you propose for the TCK to check the errors?
I'm not sure I understand what you mean by immutable publisher/subscriber relationship, could you enlighten me? Thanks!

[smaldini]

For the errors : a Processor can receive and propagate that onError input signal after having applied some transformation or serialization, I wondered if equals check over == could make this scenario more flexible.

For the Pub/Sub relationship, I'm talking about 3#13 TCK test that forces Subscriber reference to be cleaned from Publisher where sometimes its a final reference as in a delegate pattern of a Subscriber calling an inner one. I think the test should de-reference the Publisher as well or at least provide an option for. Some will expect to clean Subscriber from a registry, some will chain-lift the Subscriber reference eventually held in a source Publisher. In other word, how we materialize the flow shouldn't be tied to a concept of registry too much as it leads into potential negative test result for valid use cases.

[viktorklang]

@smaldini True, but technically, a Processor is allowed to "recover" from an upstream onError, so I wonder how the TCK would be able to verify. Any idea how we could solve that?

IGNORE THIS (Read 2.13 and not 3.13): As for 3.13 that concerns the case when the signal methods throw exceptions and therefor violate the spec. I'm probably not understanding what you mean, could you give an example?

§3.13 intends to make sure that Publishers do not leak Subscriber references which have cancelled their subscription. How would it otherwise be guaranteed?

[viktorklang]

the question of equality was addressed while providing the rationales for the rules.