Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!mx05.eternal-september.org!.POSTED.99-92-208-198.lightspeed.sntcca.sbcglobal.net!not-for-mail
From: markspace <markspace@nospam.nospam>
Newsgroups: comp.lang.java.programmer
Subject: Re: DI/wiring
Date: Mon, 22 Apr 2013 10:59:37 -0700
Organization: A noiseless patient Spider
Lines: 44
Message-ID: <kl3tkk$3hc$1@dont-email.me>
References: <DI-wiring-20130418174944@ram.dialup.fu-berlin.de> <kkpgls$6aq$1@dont-email.me> <kl2n6i$3l5$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 22 Apr 2013 17:56:36 +0000 (UTC)
Injection-Info: mx05.eternal-september.org; posting-host="99-92-208-198.lightspeed.sntcca.sbcglobal.net:99.92.208.198"; logging-data="3628"; mail-complaints-to="abuse@eternal-september.org"
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
In-Reply-To: <kl2n6i$3l5$1@dont-email.me>
Xref: csiph.com comp.lang.java.programmer:23569

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() ); }
}

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'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.