On Wednesday, 30 May 2012 at 06:31:32 UTC, Dmitry Olshansky wrote:
I'll intervene. Following famous nerd motto "talk is cheap, show me the code" I strongly suggest discussing concrete scenarios. All "prone to deadlock sentiment" is trivia as in buyer beware.That being said: class iMutexed {//implicit intent, explicit details Mutex mutex; } vs class iMutexed {//implicit intent, implicit details //implicit mutex }Makes little to no difference. EXCEPT that designer of the class has no control what so ever over hidden mutex! Thus I believe the best way to fix it is to (say) require obj be a subclass of Mutex in order to use synchronized(obj). i.e.class iMutexed: Mutex {//explicit intent, implicit details }
Forcing synchronized classes to extend Mutex would make it impossible to create a synchronized subclass of a pre-existing unsynchronized class, would it not? Unless you want to introduce multiple inheritence. If you want to go this way at least make it an interface that has special meaning to the compiler, instead of a class that must be inherited from.
