Am 04.02.2011 13:26, schrieb bearophile:
I have found an interesting post by Scott Johnson in this Lambda the Ultimate
thread:
http://lambda-the-ultimate.org/node/724#comment-6621
He says:
9th circle: Concurrent mutable state. The obnoxious practice of mutating shared state from
multiple threads of control, leading into a predictable cycle of race conditions, deadlocks,
and other assorted misbehavior from which there is no return. And if a correct solution (for
synchronization) is found for a given program, chances are any substantial change to the
program will make it incorrect again. But you won't find it, instead your customer will.
Despite that, reams of code (and TONS of middleware) has been written to try and make this
tractable. And don't get me started on a certain programming language which starts with
"J" that saw fit to make EVERY object have its very own monitor....<
This is just one quotation, but I have found similar comments four or five
other times around the Web.
So is the design choice of copying this part of the Java design inside D good?
I'd like opinions on this topic.
Recently I have suggested an optional @nomonitor annotation for D classes (to
optionally remove a word from class instances and to reduce class instantiation
overhead a bit). Another option is doing the opposite, and defining a
@withmonitor annotation where you want a class to have a monitor.
Bye,
bearophile
Please note that D has a syntax for such things (optimizations with
little behavior change). It called 'pragma'. Exchange @nomonitor with
pragma(nomonitor) and I'm for your idea. pragma looks and feels better IMO.
Mafi
PS: cant see any @ttributes more :(
