Changes to JEP 453

[Rob Bygrave]

*> all Concurrent Tasks should be Structured*

That was my thought too, there isn't a "UnstructuredTaskScope" per se [and
I don't think there will be one in the future?] ... so the "Structured"
part of StructuredTaskScope can seem unnecessary. It feels like it could be
"TaskScope" perhaps?



*> `StructuredTaskScope` is not a task though, but it is really a scope*

fwiw I agree, I think of it as a "scope" that contains "tasks" [that will
usually run concurrently].


My 1c


On Fri, 19 May 2023 at 10:01, Attila Kelemen <attila.kelemen85 at gmail.com>
wrote:

> >
> > So, what does "Subtask" mean when there is no "Task"?
> >
> >
> > Personally, I would go with either just "Task" or "StructuredScopeTask"
> as "Subtask" is sort of inventing new terminology.
> >
> > If you renamed "StructuredTaskScope" to just "Task" then "Subtask" would
> make more sense as it is something spawned from a Task. This would be my
> preferred choice. Shorter names for common things... in particular things
> that should become common.
> >
> > However, what is the relationship to "Task" with all those other things
> called "...Task..." Maybe just "ConcurrentTask" and "ConcurrentSubtask" are
> more meaningful, but "java.util.concurrent.Task" and
> "java.util.concurrent.Subtask" are probably clear enough.
> >
> > In a sense, we would be saying that all Concurrent Tasks should be
> Structured.
>
> `StructuredTaskScope` is not a task though, but it is really a scope
> (besides, a simple name like `Task` would conflict with a lot of
> existing things, which would be horrible, even if others shouldn't
> have given such a simple name as well).
>
> The way I imagine it is that the "task" you are looking for is the
> block between the creation and closing of `StructuredTaskScope`.
> Still, obviously naming this is difficult, because it is also not
> exactly a task (I mean it has a task() method for confusion, and that
> is not the parent, but actually the action of the `Subtask`, but I
> believe the `task()` method should be removed, as it is harmful). As
> far as usage goes, this wants to be a reference to the result of the
> task, but the existence of `state()` would make it awkward to call it
> some kind of result (also then `get` would return the result of a
> result, which is also awkward). So yeah, it should be
> `ResultReferenceWithStateOfComputation` :). Though, on a second note,
> it could be called result, and you could think of state as the state
> the result is in (since you are not really expected to rely on this
> changing, and should not use it before `join`).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/loom-dev/attachments/20230519/5ef753c8/attachment-0001.htm>