<div dir="ltr"><div dir="ltr">David Lloyd <<a href="mailto:david.lloyd@redhat.com">david.lloyd@redhat.com</a>> ezt írta (időpont: 2023. jún. 1., Cs, 20:35):</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif">What I for one do *not* want is for someone other than myself to decide what "properly scoped" means for a given piece of code that I write, nor do I want behavior outside what is strictly required for implementing locally scoped variables.</div><div style="font-family:arial,helvetica,sans-serif"><br></div></div></blockquote><div><br></div><div>I meant very little by "properly scoped", only that scopes organize into a single tree (assuming an implicit scope for `main`), and all code runs in a scope. You are still in complete control of how to create scope, and what scope to use.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif"></div><div style="font-family:arial,helvetica,sans-serif">Let me give a real-world example of why this is a problem. We have a security identity framework where our identities are associated in the manner of ScopedValue. A user may query what identity is currently active, and the user may execute some block of code with a new active identity. However, we found early on that some existing frameworks - like the Servlet specification for example - do not allow us to interpose a call like identity.runAs(() -> { ... }) in the midst of handling a request, for right or for wrong. So instead what we offer is a way to lexically scope a "flexible identity association". The identity may be changed within the scope of an operation, but the flexible association does not escape the bounds of the lexical scope that it was run under.</div><div style="font-family:arial,helvetica,sans-serif"><br></div></div></blockquote><div><br></div><div>In my DI framework example (of course it doesn't have to be a DI framework, the point is the lazy factory), you are currently having a different security issue. That is, at top level I bound the factory, and then lazily somewhere down (possibly in an authenticated scope) you could be running (unknowingly) the factory with credentials, and that is most certainly not something you want.</div><div><br></div><div>As for your concern: You are already screwed :) In fact, I have realized that I have a (horrible) way to implement what I want with `StructuredTaskScope`, because when I'm binding the factory in my example, I can open a new STS, fork a task immediately which will just stop and wait and when down the line the "resource" is requested, I will just let the task go, and channel back the result. Actually, I'm very glad you are making these criticisms, because it made me realize a better way to imagine what I want (functionality wise it would be the same). That is, my `CapturedScopedValueContext.inContext` method should be imagined as running a task in parallel, but the parallel task is being executed in a higher level scope. So, even if nothing else comes out of it, I'm already glad to have written this, and that you responded :)</div><div><br></div><div> </div></div></div>