<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">I 100% agree that StructuredTaskScope is a redundant stutter.<div><br></div><div>I think something like TaskSet, or TaskGroup would be much easier to use and discuss.<br><div><br><blockquote type="cite"><div>On Nov 8, 2024, at 7:26 AM, Eirik Bjørsnøs <eirbjo@gmail.com> wrote:</div><br class="Apple-interchange-newline"><div><div dir="ltr"><br><div>Hello,</div><div><br></div><div>I've been making some effort to reconcile my excitement about structured concurrency as a concept with my surprising lack of enthusiasm looking at code expressed using the API suggested in the JEPs.</div><div><br></div><div>I think a lot of it comes down to naming. Yes, I know naming is hard, and too easy to bikeshed about. But I also think it's important to get it right. APIs using well chosen names at the right abstraction level are more pleasurable to use.</div><div><br></div><div>(Disclaimer: The questions here are of mostly rhetorical nature, to prove a point or demonstrate confusion. I'm not necessarily looking for direct answers)</div><div><br></div><div>Ok, let's try to pick apart the name "StructuredTaskScope":</div><div><br></div><div>Is it a scope?</div><div>Maybe, maybe not. It seems to me that the actual "scope" here is the lexical scope - a language concept, not necessarily an API construct. Using the word "scope" in the API construct isn't wrong, it just doesn't seem to add a lot of value. Everything in programming seems to either be a scope or be in a scope..</div><div><br></div><div>Is it a task?</div><div>It seems so. It's a piece of work which can be divided into smaller tasks which can be executed concurrently, then completed as a unit.</div><div><br></div><div>Is it structured?</div><div>Sure. However, will we ever have a TaskScope which is _not_ structured? If not, "Structured" does not add much value, other than as a marketing term. I feel this will not age particularly well. Could we move it to the package name, API docs, somewhere else?</div><div><br></div><div>Now, let's look beyond the STS name and look into what we can actually _do_ with an STS:</div><div><br></div><div>scope.fork(() -> ..)</div><div>Since we're forking a scope, you may think this returns another.. scope? Ok, it doesn't. Then perhaps.. a Task? No. A SubTask! Well, then what's a Task? There is no such thing! Well, ok..</div><div><br></div><div>scope.join(): </div><div>What does it actually mean to "join a scope"? Is "join" used in a transitive or intransitive sense? Is something in the scope being joined (tasks?), or are we (the caller) "joining" the scope, like Thread::join?</div><div>Maybe the API docs give us a clue: "Waits for all subtasks started in this scope to complete". Aha, so we are "completing" the scope/tasks/subtasks. Then perhaps "join" is here just to provide symmetry with "fork" and "complete" would be a more honest name?</div><div><br></div><div>Would something like the following be an improvement?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font face="monospace">public Result performTask() {<br></font><font face="monospace"> try (TaskScope scope = TaskScope.open()) {<br></font><font face="monospace"> Task<String> task1 = scope.task(() -> query(left));<br></font><font face="monospace"> Task<Integer> task2 = scope.task(() -> query(right));<br></font><font face="monospace"> scope.complete();<br></font><font face="monospace"> return new Result(task.get(), task2.get());<br></font><font face="monospace"> }<br></font><font face="monospace">}</font></blockquote><div><br></div><div>Or perhaps get rid of "scope" completely?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><font face="monospace">public Result performTask() {<br></font><font face="monospace"> try (Task task = Task.open()) {<br></font><font face="monospace"> Subtask<String> task1 = task.subtask(() -> query(left));<br></font><font face="monospace"> Subtask<Integer> task2 = task.subtask(() -> query(right));<br></font><font face="monospace"> task.complete();<br></font><font face="monospace"> return new Result(task.get(), task2.get());<br></font><font face="monospace"> }<br></font><font face="monospace">}</font></blockquote><div><br></div><div><br></div><div>When introducing new APIs with new abstractions it's quite common that the initial naming of constructs ends up too.. abstract. While working on the API's implementation, it's also easy for implementation details to leak into the API naming. I have a feeling this may be going on here. Are we at "peak abstraction"?</div><div><br></div><div>Thanks,</div><div>Eirik.</div></div>
</div></blockquote></div><br></div></body></html>