Naming Things - Task and Subtask

[Attila Kelemen]

Just to avoid misattribution, I just realized that the API sketch
below in large part was written by Eric, I just got a little confused
in all the text :). That said, what I wrote still stands of course, I
would be curious if an API like that could be made to work.

Attila Kelemen <attila.kelemen85 at gmail.com> ezt írta (időpont: 2023.
máj. 19., P, 21:43):
>
> >
> > Attila (and still Eric)
> > It seems like both of you don’t like the TWR part, but I find it extremely nice to have, and a lot of times prefer it over a lambda argument.
> > TWR allows us to propagate checked exceptions, which till we add union-types in generic levels is impossible to do with lambdas, and it doesn’t have the (justified) restrictions of lambdas.
>
> I'm not really against having the TWR way available as a low level
> construct, I just like to have these lambda blocks as utility to which
> you resort to (although tbh, it is a bit strange that scoped values
> give you lambda block only, while STS only TWR). Of course, checked
> exceptions are a nightmare in these constructs, and that is why I
> usually have `UnsafeFunction<T, E extends Throwable>` (and its
> gazillion siblings) around (and I'm pretty sure there are many-many
> people creating their own "Unsafe" function interfaces). In an idea
> world we could have constructs similar to Kotlin's inline functions,
> which would solve this issue (fingers crossed for it :))
>
> >
> > var results = StructuredTask.StreamBuilder()
> >                                    .value<String>("USERNAME", "duke")
> >                                    .flatFork(() -> Stream.of(workers))
> >                                    .join()
> >                                    .throwIfFailed() // "StructuredTask.Stream" doesn't need a "strategy" because it exposes functions like this instead
> >                                    .map(Subtask::get) // "structured" comes into play here, you can't call terminating operators without first calling "join"
> >                                    .toList();
> >
>
> This could be nice actually, but I would just create something like
> this on top of STS, since an API like this could easily end up with
> unwanted limitation. If you have a working implementation of something
> like this, I would be curious to see it. Though I suspect an actual
> implementation has to go through some iterations (at least, when I'm
> designing APIs like this, I always have to seriously review my
> original idea). In this idea - for example - I can't see how you would
> do a conditional termination of starting new workers in a loop. For
> example, if this was a server waiting for TCP connections, and then it
> needed to fork new tasks for each incoming connection, I'm not sure
> how that would look. And also compare how particular cases would
> compare against `Stream`, because your example looks like more of a
> candidate of parallel `Stream`.