Le 30/05/2012 17:46, Andrei Alexandrescu a écrit :
On 5/30/12 2:34 AM, deadalnix wrote:
Le 29/05/2012 23:33, Andrei Alexandrescu a écrit :
On 5/29/12 1:37 AM, deadalnix wrote:
I would say that breaking things here, with the right deprecation
process, is the way to go.
So what should we use for mutex-based synchronization if we deprecate
synchronized classes?
Andrei
I think something similar to range design here is the way to go.
It is easy to define something like
template isLockable(T) {
enum isLockable = isShared!T && is(typeof(T.init.lock())) &&
is(typeof(T.init.release()));
}
And allow locking only if(isLockable!Type) .
Now we can create SyncObject or any structure we want. The point is that
we lock explicit stuff.
But in this design anyone can lock such an object, which was something
you advocated against.
Andrei
I was advocating on being able to lock ANY object, which is out of control.
Such an object is known to be lockable, and most object will not be. It
will avoid liquid lock, because most thing will not be lockable.
Combined with encapsulation capabilities that D already have, exposing
the lock to the entire worlds is easy. It will avoid unexpected lock
from 3rd party code, which is a source of tedious deadlock.
It also open door for locking on struct, that is easily embeded in a
class as value (so constructed and destructed with the class).
The fact that anyone or not can lock/unlock a mutex is a encapsulation
problem and we already have solution in D for that.
