Changes to JEP 453

[Rob Bygrave]

NOT_STARTED would be great imo !!!

*> a bit morbid*

Apologies if I'm being too blunt here. I think people will relate
'stillborn' to *'miscarriage'* and that to me means it has the potential to
"cut very deep" for too many people. IMO we don't want to be anywhere near
this subject.

On Fri, 19 May 2023 at 12:30, Josiah Noel <josiahnoel at gmail.com> wrote:

> 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/20230519/d08bc539/attachment-0001.htm>