<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=ks_c_5601-1987">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div class="elementToProof" style="text-align: left; text-indent: 0px; margin: 0px; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi Eirik,</div>
<div style="text-align: left; text-indent: 0px; margin: 0px; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="text-align: left; text-indent: 0px; margin: 0px; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thanks for your thoughts!</div>
<div style="text-align: left; text-indent: 0px; margin: 0px; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="text-align: left; text-indent: 0px; margin: 0px; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
As you can imagine, we have performed numerous experiments with different naming structures and themes, and the current selection came out as the winner.</div>
<div style="text-align: left; text-indent: 0px; margin: 0px; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="text-align: left; text-indent: 0px; margin: 0px; font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Besides the naming, do you have more feedback on the feature itself?</div>
<div id="Signature" class="elementToProof" style="color: inherit;">
<div style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Cheers,<br>
¡î</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<b><br>
</b></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<b>Viktor Klang</b></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Software Architect, Java Platform Group<br>
Oracle</div>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> loom-dev <loom-dev-retn@openjdk.org> on behalf of Eirik Bj©ªrsn©ªs <eirbjo@gmail.com><br>
<b>Sent:</b> Friday, 8 November 2024 14:26<br>
<b>To:</b> loom-dev@openjdk.org <loom-dev@openjdk.org><br>
<b>Subject:</b> API naming, StructuredTaskScope</font>
<div> </div>
</div>
<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="x_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="x_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>
</body>
</html>