Branch: Tag:

2013-07-06

2013-07-06 09:48:44 by Henrik Grubbström (Grubba) <grubba@grubba.org>

Thread: Removed inherit of Thread.Thread.

Mast explains the reason rather clearly:

The reason for its existance was that it was supposed to be
supported to be possible to write

Thread t = Thread(...);

Unfortunately that was completely and utterly wrong. The loads of
optional modifiers in the file is a telltale sign that the module
Thread, which contains tools to use with threads, and
Thread.Thread, which represents a specific thread, are two
completely different things. That being the case, it's hardly wise
to give them the same name.

An example where this stunt breaks down is when the module is
inherited: If the type name for a thread object is Thread then it's
reasonable to believe that you can inherit Thread to make a custom
thread class with some extra context. But not only do you get loads
of stuff with that inherit which are meaningless to have in a
thread instance (mutexes, queues, etc), you also get a nonworking
thread since the create function is overridden here to avoid a
thread being created when the module is created.

Using Thread as a type name for thread objects has been strongly
discouraged. I.e. use "Thread.Thread t = Thread.Thread()" and _not_
"Thread t = Thread()".

The feature has been discouraged since Pike 7.7.10 (2004-10-14), and
is likely to have been broken since at least Pike 7.7.28 (2006-04-07).

This commit also marks Thread.`()() as deprecated.

3: Inside #if constant(thread_create)
  #if constant(thread_create)   constant Thread=__builtin.thread_id;    - // The reason for this inherit is rather simple. - // It's now possible to write Thread Thread( ... ); - // - // This makes the interface look somewhat more thought-through. -  - // Unfortunately that is completely and utterly wrong. The loads of - // optional modifiers in this file is a telltale sign that the module - // Thread, which contains tools to use with threads, and - // Thread.Thread, which represent a specific thread, are two - // completely different things. That being the case, it's hardly wise - // to give them the same name. - // - // An example where this stunt breaks down is when this module is - // inherited: If the type name for a thread object is Thread then it's - // reasonable to believe that you can inherit Thread to make a custom - // thread class with some extra context. But not only do you get loads - // of stuff with that inherit which are meaningless to have in a - // thread instance (mutexes, queues, etc), you also get a nonworking - // thread since the create function is overridden here to avoid a - // thread being created when this module is created. - // - // Using Thread as a type name for thread objects is strongly - // discouraged. I.e. use "Thread.Thread t = Thread.Thread()" and _not_ - // "Thread t = Thread()". It's likely that this abomination is cleaned - // up eventually. - // - // /mast -  - inherit Thread; -  - // We don't want to create a thread of the module... - protected void create(mixed ... args) + //! Create a new thread. + //! + //! @deprecated predef::Thread.Thread + optional __deprecated__ Thread `()( mixed f, mixed ... args )   { - } -  - optional Thread `()( mixed f, mixed ... args ) - { +     return thread_create( f, @args );   }