So the purpose of TWR is to hold an object with a “close-debt”
(debt of a future call to close) and pay it at the end of a block,
sort of like C++ RAII (but also sort of not).
But fluent syntaxes (which I like very much and hope to see
more of in the future!) don’t play well with blocks, so if a
fluent chain (any part of that chain: It’s multiple objects)
incurs a “close-debt”, it’s hard to jam a TWR block into it.
Hence the current proposal. I agree with Brian and Paul
that we haven’t examined all the corners of this problem
yet. And I’d like to poke at the concept of “close-debt” to
help with the examination.
Just for brain storming, I think we could model “close-debt”
outside either fluent API structure or TWR block structure.
Java O-O APIs are the pre-eminent way to model things in
Java, and they work exceedingly well, when used with skill.
AutoCloseable models close-debt of course. But it has two
weaknesses: It doesn’t model anything *other* than the
debt, and its (sole) method skates awkwardly around the
issue of checked exceptions. (It requires an override with
exception type narrowing to be used in polite company.)
AC is more of an integration hook with TWR, rather than
a general-purpose model for close-debt. Therefore it doesn’t
teach us much about close-debt in a fluent setting.
Surely we can model close-debt better. Let’s say that an
operation (expression) with close-debt *also* has a return
value and (for grins) *also* has an exception it might throw.
This gets us to an API closer to Optional. (If you hear the
noise of a monad snuffling around in the dark outside
your tent, you are not wrong.)
interface MustClose_1<T,X> {
T get() throws X; //or could throw some Y or nothing at all
void close() throws X;
}
(I wish we had an easier way to associate such an X
with such a T, so that Stream<T throw X> could be more
interoperable with simple Stream<T>. It’s a pain to
carry around those X arguments. So I’ll drop X now.)
interface MustClose_2<T> {
T get();
void close() throws Exception;
}
An expression of this type requires (in general) two
operations to finish up: It must be closed, and the result
(type T) must be gotten. There’s an issue of coupling between
the two methods; I would say, decouple their order, so that
the “get” call, as with Optional, can be done any time,
and the “close” call can be done in any order relative
to “get”. Both calls should be idempotent, I think.
But that’s all second-order detail.
A first-order detail is the apparent but incorrect 1-1 relation
between T values and close-debts. That’s very wrong;
a closable stream on 1,000 values has one close-debt,
not 1,000. So maybe we need:
interface MustClose_3<T,U,S> {
S map(Function<T,U> value);
void close() throws Exception;
}
That “map” method looks a little like Remi’s apply
method. Did I mention this design requires skill
(as well as flexibility, with one hand already tied
by checked exceptions)? I’m at the edge of my own
skill here, but I think there’s good ground to explore
here.
In a fluent setting, a Stream<T> that incurs a close-debt
might be typed (after incurring the debt, perhaps in a
transform) as Stream<MustClose<T>>, and somehow
all consumers of the MustClose<T>, such as map and
collect operations on the Stream, would correctly
unpack each T from the MC<T>, and then repack
the result into the MC<.> wrapper.
var res = openAFileStream().map(…).collect(…);
Here the first method call returns a Stream with
close-debt mixed into its type. The map and collect
calls would wire both parts: The T values flowing
through, and the close-debt. Who takes responsibility
for paying the close debt? Maybe an extra call
at the end: …map(…).collectAndClose(…).
Or maybe the stream “knows” internally that since
its type has a close debt, all of its terminal operations
have to pay off that debt as they collect the payloads.
So it would be automatic, somehow, inside of
collect, forEach, etc.
To make the parts hook up right, you might need
reified generics, or maybe an amended type
MustCloseStream<T> <: Stream<MustClose<T>>,
like the LongStream <: Stream<Long> we dislike.
I’m only proposing as a thought exercise for now.
Maybe the MustCloseStream takes an explicit close
method which produces a regular stream over the
base type. The explicit close method would release
resources and buffer anything necessary to produce
an in-memory Stream<T>. You’d want to call it
late in the fluent chain, after filtering and flat-mapping
is done, just before a collect for forEach.
Here’s a streamlined version of MustClose that
I like, which sidesteps the problem of mutual ordering
of two methods:
interface MustClose_4<R> {
R getAndClose() throws Exception;
default void close() throws Exception { getAndClose(); }
}
Here, R is not an element type of a stream, but rather
the final result (maybe Void) of some terminal operation.
Such an interface could interact with syntax, too. For
example, it might help with TWR expressions (if we
wanted to think about that):
var res = try (expr);
// sugar for:
X res; try (MustClose_4<X> $t = expr) { res = $t.getAndClose(); };
It might help with other auto-close notations or APIs we could
cook up. For example, suppose “var x=y” were artificially restricted
from inferring a MustClose<T> type from y onto var x. Instead,
the var type would be inferred as T, and a getAndClose call would
be added to the initializer (y) to unwrap the value before binding
to x. Perhaps that would stretch “var” too far; maybe we would
choose to mark such “var”s specially, as “try var x = y;”. My
point here is that an O-O model of close-debt as a wrapper for
other computations is helpful for evaluating our options.
(Another kind of wrapper for try-var would be an exception
wrapper, a direct-sum thingy which holds *either* a normal
T result or an exceptional X result. That could model things
we don’t have good models for today. In “try var x = y;” if
y is of type ValueOrException<T,X>, then var would be inferred
from T, and any X present would pop out when the initializer
were executed. You could use such a type, and such a notation,
to more easily wire exceptions through all sorts of combinators
where exceptions are not welcome today.)
To summarize: We can (and should) try to model “close-debt”
using interfaces. Doing so opens up the usual cans of worms
with interoperability and exceptions, but still gives us a
model we can contemplate. We can (and should) contemplate
how such a model would give us leverage for further syntax
sugar and/or combinatorial API points for handling close-debt
at various points in the language and our APIs.
