Loose ends: Optional -> CompletableFuture -> Eventual

[Doug Lea]

On 06/27/13 13:48, Sam Pullara wrote:
> I definitely think we should make these consistent.  I think that whenPresent is a better name even for optional.
>

(Why am I not surprised that you are first to express support? :-)


>> The least kludgy way is to share an interface. Which I'm
>> even in favor of, because it addresses a related request
>> of having some read-only-ish view on top of CompletableFuture,
>> that we had put off due to lack of consensus.

I'm now starting to remember some of the impediments.
Among them:

* As we discussed recently in related contexts, flatMap
is a hostile case. Because of limitations in type
system, we really don't want to include a method
with a function param that has a type referring to This type
unless it is a pervasive commonly used type.
Which Eventual is not designed to be.
And there are several more in CompletableFuture that
can't be nicely lifted up for basically the same reason.

* CompletableFuture uses some method naming conventions
that allow it to support consuming-style vs propagating-style
methods (like thenAccept vs thenApply) that cannot share names
because of overload ambiguities that would be frequently
encountered by users. Lifting up these conventions to an
interface shared with Optional makes Optional needlessly
strange-looking.

* If you remove lambda-accepting methods one by one for reasons
like the above, you are left with only get() and isPresent()
as a shared interface. It is not helping anyone to
place this in java.util.

So I'm at the moment thinking that it is better to live with
inconsistency than to introduce more problems.
Does anyone see a good way out?

Assuming not, I still do owe all of those people who were so
unhappy about tabling discussion of a read-only interface for
CompletableFuture another shot at it in light of the
fact that we've nailed down other issues whose pending
status was the main reason for dropping.

Stay tuned for a less ambitious attempt at that.
(Basic idea: it must NOT include methods that
directly alter completion state: complete(),
cancel(), etc. And need not include 100% of others,
but only a minimal set expected to be relied on in layered
APIs. Judgement calls galore.)

-Doug