Path: csiph.com!usenet.pasdenom.info!news.albasani.net!eternal-september.org!feeder.eternal-september.org!mx05.eternal-september.org!.POSTED!not-for-mail From: Daniele Futtorovic Newsgroups: comp.lang.java.programmer Subject: Re: DI/wiring Date: Wed, 24 Apr 2013 06:37:35 +0200 Organization: A noiseless patient Spider Lines: 89 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Injection-Date: Wed, 24 Apr 2013 04:34:32 +0000 (UTC) Injection-Info: mx05.eternal-september.org; posting-host="f701c873d1c9639558344ff9364b0d50"; logging-data="2234"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/ckhS1npAxnqlhDUL8TN/n" User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 In-Reply-To: Cancel-Lock: sha1:UIJxKEptw/r71O607LyEV9hpOeQ= Xref: csiph.com comp.lang.java.programmer:23610 On 22/04/2013 19:59, markspace allegedly wrote: > On 4/22/2013 12:03 AM, Daniele Futtorovic wrote: >> >> In code terms, instead of: >> class Actor { >> void act( Context c ){ doSomethingWith( c.getXXX() ); } >> } > > Just to be clear, I was advocating using constructors, not method > parameters: > > public class Actor { > private Context c; > public Actor( Context c ) {this.c = c} > public void act() { doSomethingWith( c.getXXX() ); } > } Yes; this is why I spoke of "constructor or method parameters". See, the problem, or issue, with this approach is that you make the context part of the actor's state. Meaning the actor is bound to the context, rather than being context-independent. For instance, the component wouldn't be reusable for a different context. Now, there may be situations where that would be the right thing to do. Yet, because of that, this approach to me is inferior to passing the context to the main actor method (the method that encapsulates the unit of work). > This is really really different: > >> You'd have: >> class Actor { >> void act(){ >> doSomethingWith( ContextHelper.getThreadLocalContext().getXXX() ); >> } >> } > > Now actor does something different depending on what thread is invoking > a method. My class was invariant with respect to the thread invoking its > method. No matter who calls "act()" the result will always be the same. > > Since modern systems often use thread pools and the worker threads are > supposed to be generic and often randomly assigned, I can't see too many > cases where your thread local context is going to be useful. Worse, if > an generic worker thread has a context and then is assigned to another > task... the results could be random and unpredictable, and really hard > to debug as well. I'll have to disagree with you here. All systems that use thread pools will involve some sort of dispatch mechanism that consumes a queue of work units. I do not believe it is far fetched to imagine that the dispatch mechanism would run as exemplified in the following: while take-from-queue set-up-context try { execute-task } finally { clean-up-context } The only situation, then, where the ThreadLocal wouldn't work is when the work units are executed on multiple threads. I may be wrong, but I do not see this as being the majority of cases -- to the contrary. > I'm sure you must have some use case in mind where a thread local is > useful, but I'm having a hard time seeing it. It feels like you push > the context/initialization problem into the threading system, where it's > actually going to be harder to manage. In a system that was designed > from the ground up to support contexts attached to threads, OK it might > work, but in many existing systems it seems difficult to add. It is true that it is more fragile, and for that reason alone may be legitimately rejected, I'll grant you that. But it is not difficult to add; quite the contrary, it is much easier to add to an existing system than the one you suggested, because it does not involve any change in the API (only to the implementation). Now, don't get me wrong, I'm not trying to suggest this is anywhere the be-all and end-all of programming techniques. Indeed, because it is fragile and less explicit (and hence more difficult to grasp) than the other way (passing a context to the actor's method), the latter is my preferred and indeed the standard approach I opt for when designing a piece of code that involves a dispatch mechanism (which is most of them). I merely intended to mention that other possibility for the record. -- DF.