This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
jon rozanski wrote:Here (name referencing threads) they mention a way to reference threads by their name, but yes, it seems much easier to do this with an array
Yes, you can name threads, but I don't see how that helps you to reference a thread. I've seen thread names used to identify individual threads in log messages, for example. If I want a thread to do my bidding, then I need a reference to it, and that would be a variable, not the thread's name.
Joined: Dec 04, 2012
On that link the show this to reference a thread by name
That does not look a very efficient way to get threads by name. And why would you want to?
It might be better to put the threads and their names (or more precisely the other way round) into a Map<String, Thread>. But again, why would you want to do it?
This appears to be a new question on an old discussion; please don’t do that. I can create a new discussion for the new question, fortunately.
Yes, you could do that. But in my opinion if you expect that you're going to have to work with an object, your design should just keep a reference to that object, instead of trying to scavenge it back from the environment later. You have there a hack which works with Thread objects, but not with any other kind of objects.
And likewise if you're changing your design and you find you have to work with an object which you don't have a handy reference to, then you should change the design in such a way that you start keeping that reference around.