Override mutating CompletableFuture methods to throw UOE

[viktorklang]

In private class CF[T] extends CompletableFuture[T] with (Try[T] => Unit) { as an example.
So if a Java user downcasts to CompletableFuture, it won't go haywire.

[retronym]

@viktorklang Is this still relevant if we start to support toCompletableFuture as proposed in #49 ?

[viktorklang]

No, I am still unsure what the actual behavior will be once we have 2 disparate completion venues (this Issue wants to remove one of the venues).

What's your thinking on how it ought to work?

[retronym]

I'm not 100% sure what problem we're trying to solve: I'd appreciate a test case to show what you mean by haywire.

Do you mean that a user might expect the following assertion to hold?

val p = Promise[String]()
val cs = toJava(p.future)
cs.asInstanceOf[CompletionStage].complete("done")
assert(p.isComplete)

That was what I was trying to explore in retronym@9805415

[viktorklang]

What happens when both the s.c.Future and the CompletableFuture gets completed, in different ordering?
What happens when obtrudeValue / obtrudeException is used?

[retronym]

I think the semantics should be the same as if two places complete a completablefuture.

[viktorklang]

@retronym But obtrude has different semantics?

[retronym]

I would really appreciate some help to get this right. As I'm not an expert in this domain, but I do understand test cases, would you be able to contribute some (passing or failing)? Otherwise, please assume I know nothing and elaborate a little bit more with your review comments :)

[viktorklang]

I won't be able to have a look at it until next week, if that's OK?

[retronym]

No probs, this isn't urgent, I just wanted to get the ball rolling.

[viktorklang]

Great, ping me on monday so we can see how to deal with this.

[ryantheleach]

@viktorklang @retronym It's well past monday, just figured you would want a ping anyway?

[viktorklang]

LOL

Thanks @ryantheleach, I'll have a look at it when I can (swamped this week). :)