
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr"></div><div dir="ltr">Yes. Use lisp if you want that. Java doesn’t need it. </div><div dir="ltr"><br></div><div dir="ltr">A great developer can write great code given tools they understand. If your hammer turns in a screwdriver that might be great for people needing a screwdriver. But they should have started with one. </div><div dir="ltr"><br></div><div dir="ltr">The complexity of a system cannot be judged by designer - it can only be judged by those that maintain it. </div><div dir="ltr"><br><blockquote type="cite">On Jun 1, 2023, at 11:36 PM, Rosetta Roberts <rosettafroberts@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="auto"><div>This sort of scoping isn't a new paradigm. It is equivalent to dynamic scoping which was present in the original lisp introduced in 1960; it is older than C.</div><div dir="auto"><br></div><div dir="auto">Though, I think using scoping like this for resource management or dependency injection is still rather new.<br><br><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">On Thu, Jun 1, 2023, 23:28 Robert Engels <<a href="mailto:rengels@ix.netcom.com">rengels@ix.netcom.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div dir="ltr"></div><div dir="ltr">I think you would really like Rust. </div><div dir="ltr"><br></div><div dir="ltr">Java needs to stop trying to address every new paradigm that becomes hot. </div><div dir="ltr"><br></div><div dir="ltr">People wrote really great software in Java 1. This continual added complexity is only going to make it obsolete. </div><div dir="ltr"><br></div><div dir="ltr">If it doesn’t read like Java - it’s not Java - and it doesn’t belong. </div><div dir="ltr"><br></div><div dir="ltr">Create the fiefdoms elsewhere. </div><div dir="ltr"><br><blockquote type="cite">On Jun 1, 2023, at 5:15 PM, Attila Kelemen <<a href="mailto:attila.kelemen85@gmail.com" target="_blank" rel="noreferrer">attila.kelemen85@gmail.com</a>> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><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 class="gmail_quote"><div><br></div><div>But this is a cross thread relationship, right? The scoping in this case is transversal to lexical scoping or thread scoping. A bean that is bound to some sub-context of the application context, is bound during a time that is defined by the application life cycle, not by some call chain active in some thread. Why would one implement all this inside ScopedValue?</div></div><div><br></div></div></blockquote><div><br></div><div>The way I imagine, is that in the future you could design an application around scopes (in the abstract, SV is just a visible thing in the scope). That is, all your application is a single tree of scopes, and all the application code is within a scope. In this world, scopes would be a natural candidate to be used as DI contexts, because scopes have a well defined life-cycle, and that would make arguing about the lifetime and ownership (and who can have access to them) of resources easy. To me at least it is always a big pain point that it is hard to prove that a resource that has a given lifetime is not used outside its lifetime, and also that I can limit its life to a minimum. And since scopes would/could be the owner of resources, it makes sense to inject them via the scopes as well (since you know that whatever you injected this way is alive at that point).</div><div> </div></div></div>

</div></blockquote></div></blockquote></div></div></div>

</div></blockquote></body></html>