Changes to JEP 453

[Josiah Noel]

I suppose it is a bit morbid, perhaps NOT_STARTED would be better?

On Thu, May 18, 2023, 8:26 PM Rob Bygrave <robin.bygrave at gmail.com> wrote:

> *>  `STILLBORN` state*
>
> My feedback - I'd look for another name for this state. That word might be
> a fairly deep emotional trigger for some folks so imo I'd hope for an
> alternative for that state.
>
> Now 2c
>
> On Fri, 19 May 2023 at 12:17, Rob Bygrave <robin.bygrave at gmail.com> wrote:
>
>> *> 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/20230518/ff690f03/attachment.htm>