== Quote from Steven Schveighoffer (schvei...@yahoo.com)'s article > On Wed, 08 Jul 2009 19:34:51 -0400, Bartosz Milewski > <bartosz-nos...@relisoft.com> wrote: > > Walter Bright Wrote: > > > >> http://www.reddit.com/r/programming/comments/8z3wm/whats_wrong_with_the_thread_object/ > > > > The bottom line of this post is that the current Thread object in D > > should be abandoned and replaced by a more primitive "spawn" function. > > If there are no serious objections, we are going to proceed with the > > rewrite. > I'd be interested to know if Sean has seen this. > What you lose in not having a primitive thread be a class is that it's > more difficult to hook thread runtime events. However, looking at the > thread class, nothing is hookable through overriding except for run, which > means you have a very valid point.
Even run isn't supposed to be overridable, as it's a private method. This works only because of a compiler bug. > In fact, you could probably implement the current Thread on top of your > spawn function. I think it would be a good boilerplate thing, since a > thread's functionality is often well encapsulated as an object. Not to > mention existing code (and lots of it!). It would be trivial to implement spawn on top of the Thread object. And the reverse would work as well, though it would be less practical. After all, some data must be used to represent a thread even with the spawn model, and it would be silly to graft a thread abstraction a few layers above this.