On Wednesday, 14 May 2014 at 11:14:47 UTC, bearophile wrote:
> I suggest a name like "@monitor". The is no need for the underscores.
Done.

> A more tidy design could require the @monitor in all classes that inherit from a @monitor-annotated class. But this also looks a little overkill. So let's hear what other people think about this.
It should be easy to implement, but i'm not sure if it will be handy. Monitors are not something that affects children behavior too much. So changing a superclass to be @monitored should not require updating subclasses. IMHO.

Yuriy:

> 2. class may be defined with @__monitor attribute, in which case a __monitor variable will be added to it's beginning.

I'd like to know why you think D classes should not have the monitor on default (this means why you don't plan for a @no_pointer).

Currently D classes have that pointer on default, so I think the exchange of the default should be justified with an explanation.

Most D classes are currently allocated on the heap by the D GC that has a minimal allocation size, so the save in memory is small.

Bye,
bearophile

On Wednesday, 14 May 2014 at 13:07:32 UTC, bearophile wrote:
> I'd like to know why you think D classes should not have the monitor on default (this means why you don't plan for a @no_pointer).
There are 4 reasons for that.
1. I'm thinking of monitors as members of Object class, so all other classes have monitors just because they are inheriting it. So with my proposal you would be able to add a monitor, but not remove it.
2. Mutex synchronization is pretty old-school approach, there's a lot of cons to using it, and thus it should not be carved into the language core.
3. I can't imagine a project that has more than 10% of it's classes being synchronized on, so this feature looks like more often unneeded than needed.
4. I consider D a killemall language, that may be potentially used on tiny AVRs and PICs, where polymorphism might be welcome, but an extra pointer for each class instance may become a blocker. I know, thats fantasy now, but i think it's crucial to keep this concept of D.

Yuriy:

> 4. I consider D a killemall language, that may be potentially used on tiny AVRs and PICs, where polymorphism might be welcome, but an extra pointer for each class instance may become a blocker. I know, thats fantasy now, but i think it's crucial to keep this concept of D.

It's wiser to not dream too much :-)

I leave the more complex parts of this discussion to people that know the topic more than me.

Bye,
bearophile

On Wednesday, 14 May 2014 at 11:06:43 UTC, Yuriy wrote:
> bearophile, good point. What do you think of the following solution:
> 1. Declaring member variable with __monitor identifier is disallowed.
> 2. class may be defined with @__monitor attribute, in which case a __monitor variable will be added to it's beginning.
> 3. Subclass of such class may again be defined with @__monitor attar, in which case it will be simply ignored, as it already inherits __monitor from super.

These would be breaking changes. I see the benefit but...

If the compiler recognizes the class using synchronized, it could
use a little magic and add a monitor variable itself, this would
not cause any breaking change.

On Wednesday, 14 May 2014 at 13:53:51 UTC, Damian Day wrote:
> These would be breaking changes. I see the benefit but...
Breaking, only if someone used to define __monitor in his class. Which is kinda weird, and according to docs (identifiers starting with __ should are reserved). Or if someone used to access __monitor field of something, which is also kinda weird. Otherwise, no breaking changes here.

> If the compiler recognizes the class using synchronized, it could
> use a little magic and add a monitor variable itself, this would
> not cause any breaking change.
I guess it would need a whole lot of magic, since synchronized() is normally used outside of class and even its module, except for synchronized(this) or smth. And adding members in compile-time to classes defined in not_current_module sounds like a bad idea.
However, compiler could do some little magic, adding __monitor to a class, if it can prove that synchronized is used in the same module where class is defined.
Another however, i'm not sure if such optimization is even worth thinking of, since you still can sync on any class regardless it defines __monitor or not.

On Wednesday, 14 May 2014 at 14:07:50 UTC, Yuriy wrote:
> On Wednesday, 14 May 2014 at 13:53:51 UTC, Damian Day wrote:
>> These would be breaking changes. I see the benefit but...
> Breaking, only if someone used to define __monitor in his class. Which is kinda weird, and according to docs (identifiers starting with __ should are reserved). Or if someone used to access __monitor field of something, which is also kinda weird. Otherwise, no breaking changes here.

The object's layout and size also change, but the layout of objects is implementation defined AFAIK, and its size shouldn't be hard-coded anyway, so the breakage is minimal.

On Wednesday, 14 May 2014 at 14:44:07 UTC, Marc Schütz wrote:
> The object's layout and size also change, but the layout of objects is implementation defined AFAIK, and its size shouldn't be hard-coded anyway, so the breakage is minimal.
You're right. Shared libraries will need to be rebuilt.

Meanwhile, i've updated the PRs according to latest notes. @monitor attr, forbid __monitor declaration, so everyone can have some fun with it. =)

Actually, I prefer your original proposal @no_monitor as I expect D classes to have monitors by default, until D eventually changes. Having @monitor implies that by default there are no monitors (which makes sense, but unfortunatelly that is not the current state of affairs in D).

Yuriy:

> Meanwhile, i've updated the PRs according to latest notes. @monitor attr, forbid __monitor declaration, so everyone can have some fun with it. =)

You are good. Before this is ready for Walter's judgement I think this needs some simple performance/memory benchmarks, to compare the situation before and after this change.

Bye,
bearophile