In message <uwtm242yy.fsf@boost-consulting.com>, David Abrahams <dave@boost-consulting.com> writes
"John Maddock" <john@johnmaddock.co.uk> writes:
The reason I threw this one in, is that there was a suggestion (from Kevlin Henney's thread proposal if I remember correctly) to decouple thread object creation, from the actual execution of the thread, so that then we can tweak the threads properties with getters/setters before we execute the thread (think thread priority, scheduling policy etc).
Does this make sense or am I barking up the wrong tree?
Usually when I hear "let's make an instance in a special not-fully-functional state so we can tweak it with getters and setters before we really bring it to life," little alarm bells go off. It complicates the object invariant and injects often-unwanted state into the program. How about using the parameter library to set these things up?
Just to clarify, my proposal was that things like these would get passed in as parameters of thread creation, so constructor arguments, not post-construction setters. Once a thread is running there are only a few properties that would be sensibly amenable to "getters and setters", such as execution priority. Kevlin -- ____________________________________________________________ Kevlin Henney phone: +44 117 942 2990 mailto:kevlin@curbralan.com mobile: +44 7801 073 508 http://www.curbralan.com fax: +44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ____________________________________________________________