Re: Synchronized classes have no public members

On Tuesday, 20 October 2015 at 18:15:05 UTC, Bruno Medeiros wrote: On 16/10/2015 08:02, Jacob Carlborg wrote: On 2015-10-16 08:49, Dicebot wrote: As far as I understand topic is about deprecating direct field access of synchronized classes, method calls in synhronized classes and

Re: Synchronized classes have no public members

On 16/10/2015 08:02, Jacob Carlborg wrote: On 2015-10-16 08:49, Dicebot wrote: As far as I understand topic is about deprecating direct field access of synchronized classes, method calls in synhronized classes and `synchronized () {}` blocks will remain untouched. Is it even possible to do

Re: Synchronized classes have no public members

On Sunday, 18 October 2015 at 15:51:50 UTC, Jacob Carlborg wrote: On 2015-10-16 23:54, Jonathan M Davis wrote: Basically all of the usage of the "synchronized" keyword in DWT is actually the synchronized statement. I found a couple of more false positives where "synchronized" was part of a

Re: Synchronized classes have no public members

On 2015-10-16 23:54, Jonathan M Davis wrote: Well, you probably will at some point, even if you don't know. According to TDPL, there's not supposed to be any such thing as a class with some functions which are synchronized and some not. The entire class is synchronized or none of it is, and if

Re: Synchronized classes have no public members

On Tuesday, 13 October 2015 at 11:51:02 UTC, ponce wrote: On Tuesday, 13 October 2015 at 10:57:55 UTC, Marco Leise wrote: Yep, I prefer to think it sets of variables that need mutex protection. And these are not generally the set of member fields in a class. Exactly. And that makes things

Re: Synchronized classes have no public members

On Friday, 16 October 2015 at 06:49:06 UTC, Dicebot wrote: On Friday, 16 October 2015 at 06:26:30 UTC, Jacob Carlborg wrote: On 2015-10-15 16:28, Andrei Alexandrescu wrote: That may be worrisome. Any information on how many are using DWT, and how badly it would break if we pulled the change?

Re: Synchronized classes have no public members

On Friday, 16 October 2015 at 21:54:11 UTC, Jonathan M Davis wrote: [...] std.concurrency.MessageBox is an example of why you might mix synchronized and non-synchronized data in a class. No methods are synchronized though because it's too blunt an instrument. Synchronization happens

Re: Synchronized classes have no public members

On 2015-10-16 16:07, Dicebot wrote: That would be really bold thing to do, I don't think anyone realistically proposes that. At most I'd suggest to explicitly mark it in spec / documentation as legacy and unidiomatic feature with no deprecation. Removing it does no benefit at this point (even

Re: Synchronized classes have no public members

On Friday, 16 October 2015 at 18:50:20 UTC, Jacob Carlborg wrote: On 2015-10-16 16:07, Dicebot wrote: That would be really bold thing to do, I don't think anyone realistically proposes that. At most I'd suggest to explicitly mark it in spec / documentation as legacy and unidiomatic feature

Re: Synchronized classes have no public members

On Friday, 16 October 2015 at 06:26:30 UTC, Jacob Carlborg wrote: On 2015-10-15 16:28, Andrei Alexandrescu wrote: That may be worrisome. Any information on how many are using DWT, and how badly it would break if we pulled the change? If we assess there's too much breakage, we can define a

Re: Synchronized classes have no public members

On Friday, 16 October 2015 at 07:02:54 UTC, Jacob Carlborg wrote: On 2015-10-16 08:49, Dicebot wrote: As far as I understand topic is about deprecating direct field access of synchronized classes, method calls in synhronized classes and `synchronized () {}` blocks will remain untouched. Is

Re: Synchronized classes have no public members

On 2015-10-16 08:49, Dicebot wrote: As far as I understand topic is about deprecating direct field access of synchronized classes, method calls in synhronized classes and `synchronized () {}` blocks will remain untouched. Yeah, that was the original topic. Then I interpreted it like all uses

Re: Synchronized classes have no public members

On 2015-10-16 08:49, Dicebot wrote: As far as I understand topic is about deprecating direct field access of synchronized classes, method calls in synhronized classes and `synchronized () {}` blocks will remain untouched. Is it even possible to do synchronized classes in Java? That is, but

Re: Synchronized classes have no public members

On 2015-10-15 16:28, Andrei Alexandrescu wrote: That may be worrisome. Any information on how many are using DWT, and how badly it would break if we pulled the change? If we assess there's too much breakage, we can define a DIP and make the check opt-in via a flag -dipNN. I would like to add

Re: Synchronized classes have no public members

On Friday, 16 October 2015 at 07:00:42 UTC, Jacob Carlborg wrote: Yeah, that was the original topic. Then I interpreted it like all uses of "synchronized" would be deprecated. That would be really bold thing to do, I don't think anyone realistically proposes that. At most I'd suggest to

Re: Synchronized classes have no public members

On Friday, 16 October 2015 at 14:07:44 UTC, Dicebot wrote: On Friday, 16 October 2015 at 07:00:42 UTC, Jacob Carlborg wrote: Yeah, that was the original topic. Then I interpreted it like all uses of "synchronized" would be deprecated. That would be really bold thing to do, I don't think

Re: Synchronized classes have no public members

On 10/14/15 6:33 AM, flamencofantasy wrote: On Tuesday, 13 October 2015 at 19:05:31 UTC, Dicebot wrote: On Tuesday, 13 October 2015 at 18:28:23 UTC, Marco Leise wrote: Guys, sorry to break into your wishful thinking, but synchronized(mutex) {} already works as you want it to since as long

Re: Synchronized classes have no public members

On 10/13/15 10:05 PM, Dicebot wrote: On Tuesday, 13 October 2015 at 18:28:23 UTC, Marco Leise wrote: Guys, sorry to break into your wishful thinking, but synchronized(mutex) {} already works as you want it to since as long as I can think. Yes, it takes a parameter, yes it calls lock/unlock

Re: Synchronized classes have no public members

On Thursday, 15 October 2015 at 10:11:06 UTC, Andrei Alexandrescu wrote: Now we believe an incomplete language definition is damaging the language as a whole so we better make them fully defined and useful within their charter. +1! --- Paolo

Re: Synchronized classes have no public members

On 13-Oct-2015 21:28, Marco Leise wrote: Am Tue, 13 Oct 2015 12:52:55 + [snip] Guys, sorry to break into your wishful thinking, but synchronized(mutex) {} already works as you want it to since as long as I can think. Yes, it takes a parameter, yes it calls lock/unlock on the mutex.

Re: Synchronized classes have no public members

On Thursday, 15 October 2015 at 10:11:06 UTC, Andrei Alexandrescu wrote: On 10/13/15 10:05 PM, Dicebot wrote: On Tuesday, 13 October 2015 at 18:28:23 UTC, Marco Leise wrote: Guys, sorry to break into your wishful thinking, but synchronized(mutex) {} already works as you want it to since

Re: Synchronized classes have no public members

On Thursday, 15 October 2015 at 10:11:06 UTC, Andrei Alexandrescu wrote: Yes, and I am saying that it doesn't justify presence of `synchronized` keyword in the language at all, being historical legacy misfeature. For a while we were of the opinion that we should let "synchronized" and

Re: Synchronized classes have no public members

On 10/14/15 9:24 AM, Jacob Carlborg wrote: On 2015-10-13 14:56, Dicebot wrote: I still have no idea why I would ever use `synchronized` (any automatic thread synchronization is harmful in my opinion) so change itself is irrelevant. But it may break quite some old Java-liked 3d party code for

Re: Synchronized classes have no public members

On 10/13/15 2:58 AM, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/dmd/pull/5188 implements a rule defined in TDPL: synchronized classes shall have no public members. When I first read this, I thought "how the hell will you use this thing then?" Then aft

Re: Synchronized classes have no public members

On 10/15/15 6:20 PM, Steven Schveighoffer wrote: On 10/13/15 2:58 AM, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/dmd/pull/5188 implements a rule defined in TDPL: synchronized classes shall have no public members. When I first read this, I thought "how the

Re: Synchronized classes have no public members

On 10/15/15 4:06 AM, Dmitry Olshansky wrote: On 13-Oct-2015 21:28, Marco Leise wrote: Am Tue, 13 Oct 2015 12:52:55 + [snip] Guys, sorry to break into your wishful thinking, but synchronized(mutex) {} already works as you want it to since as long as I can think. Yes, it takes a

Re: Synchronized classes have no public members

On Thursday, 15 October 2015 at 15:20:25 UTC, Steven Schveighoffer wrote: On 10/13/15 2:58 AM, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/dmd/pull/5188 implements a rule defined in TDPL: synchronized classes shall have no public members. When I first read this, I

Re: Synchronized classes have no public members

On Thursday, 15 October 2015 at 15:16:59 UTC, Steven Schveighoffer wrote: I don't really understand all the disdain for synchronized here... Because it's usually either the wrong solution or just unnecessary. If you are going to have a single mutex for an entire object, then it's nice in the

Re: Synchronized classes have no public members

On Thursday, 15 October 2015 at 14:28:00 UTC, Andrei Alexandrescu wrote: On 10/14/15 9:24 AM, Jacob Carlborg wrote: On 2015-10-13 14:56, Dicebot wrote: I still have no idea why I would ever use `synchronized` (any automatic thread synchronization is harmful in my opinion) so change itself is

Re: Synchronized classes have no public members

On Thursday, 15 October 2015 at 10:11:06 UTC, Andrei Alexandrescu wrote: For a while we were of the opinion that we should let "synchronized" and "shared" be and move on with alternative features. Now we believe an incomplete language definition is damaging the language as a whole so we better

Re: Synchronized classes have no public members

On 2015-10-15 16:28, Andrei Alexandrescu wrote: That may be worrisome. Any information on how many are using DWT, and how badly it would break if we pulled the change? I have no idea how many are using DWT. At least a couple of developers, i.e. that I see in PR's and on the forum. grep

Re: Synchronized classes have no public members

On 10/15/15 11:50 AM, Jonathan M Davis wrote: On Thursday, 15 October 2015 at 15:16:59 UTC, Steven Schveighoffer wrote: I don't really understand all the disdain for synchronized here... Because it's usually either the wrong solution or just unnecessary. If you are going to have a single

Re: Synchronized classes have no public members

On Thursday, 15 October 2015 at 17:10:23 UTC, Steven Schveighoffer wrote: You can do both of these with synchronized statements, mutex.unlock works and you can use with a condition variable. As I said before, with the Guard lock, you have more room for error, and visually the lock is better

Re: Synchronized classes have no public members

On 2015-10-13 14:56, Dicebot wrote: I still have no idea why I would ever use `synchronized` (any automatic thread synchronization is harmful in my opinion) so change itself is irrelevant. But it may break quite some old Java-liked 3d party code for no benefit and that would be annoying. Like

Re: Synchronized classes have no public members

On 10/14/15 03:10, Kapps via Digitalmars-d wrote: > On Tuesday, 13 October 2015 at 18:28:23 UTC, Marco Leise wrote: >> >> Guys, sorry to break into your wishful thinking, but >> >>synchronized(mutex) {} >> >> already works as you want it to since as long as I can think. Yes, it takes >> a

Re: Synchronized classes have no public members

On Tuesday, 13 October 2015 at 19:05:31 UTC, Dicebot wrote: On Tuesday, 13 October 2015 at 18:28:23 UTC, Marco Leise wrote: Guys, sorry to break into your wishful thinking, but synchronized(mutex) {} already works as you want it to since as long as I can think. Yes, it takes a parameter,

Re: Synchronized classes have no public members

On Tuesday, 13 October 2015 at 06:58:28 UTC, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/dmd/pull/5188 implements a rule defined in TDPL: synchronized classes shall have no public members. The motivation behind this limitation is that member accesses in synchronized

Re: Synchronized classes have no public members

On Tuesday, 13 October 2015 at 06:58:28 UTC, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/dmd/pull/5188 implements a rule defined in TDPL: synchronized classes shall have no public members. The motivation behind this limitation is that member accesses in synchronized

Re: Synchronized classes have no public members

On Tuesday, 13 October 2015 at 07:17:20 UTC, Jonathan M Davis wrote: Ultimately, I think that we're better off with TDPL's definition of synchronized classes than the synchronized functions that we have now, so I do think that the change should be made. However, I also think that

Synchronized classes have no public members

https://github.com/D-Programming-Language/dmd/pull/5188 implements a rule defined in TDPL: synchronized classes shall have no public members. The motivation behind this limitation is that member accesses in synchronized objects should not occur without some handshake occurring. Public members

Re: Synchronized classes have no public members

On Tuesday, 13 October 2015 at 08:55:26 UTC, Benjamin Thaut wrote: I have to agree here. I think synchronized classes are of very little use, especially because they don't "cast away" shared in a useful way. It still has to be done manually. I think we should remove them. Synchronized

Re: Synchronized classes have no public members

Am Tue, 13 Oct 2015 09:36:22 + schrieb ponce : > On Tuesday, 13 October 2015 at 09:07:54 UTC, Chris wrote: > > On Tuesday, 13 October 2015 at 08:55:26 UTC, Benjamin Thaut > > wrote: > >> > >> […] The entire synchronized methods give the user the feeling > >> that he

Re: Synchronized classes have no public members

On Tuesday, 13 October 2015 at 09:07:54 UTC, Chris wrote: On Tuesday, 13 October 2015 at 08:55:26 UTC, Benjamin Thaut wrote: I have to agree here. I think synchronized classes are of very little use, especially because they don't "cast away" shared in a useful way. It still has to be done

Re: Synchronized classes have no public members

On Tuesday, 13 October 2015 at 09:36:23 UTC, ponce wrote: It's also difficult to explain: what is a "monitor"? Not difficult? A monitor is facade/object which only allows one method to execute concurrently. It can work out ok if synchronization/lockfree mechanisms are built into the

Re: Synchronized classes have no public members

On Tuesday, 13 October 2015 at 06:58:28 UTC, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/dmd/pull/5188 implements a rule defined in TDPL: synchronized classes shall have no public members. The motivation behind this limitation is that member accesses in synchronized

Re: Synchronized classes have no public members

On Tuesday, 13 October 2015 at 10:57:55 UTC, Marco Leise wrote: Yep, I prefer to think it sets of variables that need mutex protection. And these are not generally the set of member fields in a class. Exactly. And that makes things using synchronized prone to longer and more frequent

Re: Synchronized classes have no public members

On Tuesday, 13 October 2015 at 08:55:26 UTC, Benjamin Thaut wrote: On Tuesday, 13 October 2015 at 07:17:20 UTC, Jonathan M Davis wrote: Ultimately, I think that we're better off with TDPL's definition of synchronized classes than the synchronized functions that we have now, so I do think

Re: Synchronized classes have no public members

On Tuesday, 13 October 2015 at 12:20:17 UTC, Minas Mina wrote: I agree that synchronized classes / functions that not that useful. But synchronized statements, to me, make the intention of locking explicit. Synchronized statements are fine and serve a good purpose, no need to delete them

Re: Synchronized classes have no public members

On Tuesday, 13 October 2015 at 12:51:14 UTC, Benjamin Thaut wrote: On Tuesday, 13 October 2015 at 12:20:17 UTC, Minas Mina wrote: I agree that synchronized classes / functions that not that useful. But synchronized statements, to me, make the intention of locking explicit. Synchronized

Re: Synchronized classes have no public members

On Tuesday, 13 October 2015 at 18:28:23 UTC, Marco Leise wrote: Guys, sorry to break into your wishful thinking, but synchronized(mutex) {} already works as you want it to since as long as I can think. Yes, it takes a parameter, yes it calls lock/unlock on the mutex. :) Yes, and I am

Re: Synchronized classes have no public members

On Tuesday, 13 October 2015 at 19:05:31 UTC, Dicebot wrote: On Tuesday, 13 October 2015 at 18:28:23 UTC, Marco Leise wrote: Guys, sorry to break into your wishful thinking, but synchronized(mutex) {} already works as you want it to since as long as I can think. Yes, it takes a parameter,

Re: Synchronized classes have no public members

On Tuesday, 13 October 2015 at 18:27:43 UTC, Jonathan M Davis wrote: they should be creating multiple mutexes. Having a single mutex for a class is usually overly broad - regardless of whether all of the functions in a class are synchronized or only select ones are. And when you _do_ use a

Re: Synchronized classes have no public members

On Tuesday, 13 October 2015 at 08:55:26 UTC, Benjamin Thaut wrote: I have to agree here. I think synchronized classes are of very little use, especially because they don't "cast away" shared in a useful way. It still has to be done manually. I think we should remove them. Synchronized methods

Re: Synchronized classes have no public members

Am Tue, 13 Oct 2015 12:52:55 + schrieb Dicebot : > On Tuesday, 13 October 2015 at 12:51:14 UTC, Benjamin Thaut wrote: > > On Tuesday, 13 October 2015 at 12:20:17 UTC, Minas Mina wrote: > >> > >> I agree that synchronized classes / functions that not that > >> useful. > >>

Re: Synchronized classes have no public members

On Tuesday, 13 October 2015 at 06:58:28 UTC, Andrei Alexandrescu wrote: https://github.com/D-Programming-Language/dmd/pull/5188 implements a rule defined in TDPL: synchronized classes shall have no public members. The motivation behind this limitation is that member accesses in synchronized

Re: Synchronized classes have no public members

On Tuesday, 13 October 2015 at 18:28:23 UTC, Marco Leise wrote: Guys, sorry to break into your wishful thinking, but synchronized(mutex) {} already works as you want it to since as long as I can think. Yes, it takes a parameter, yes it calls lock/unlock on the mutex. :) Though really,