Events in D

[bitwise via Digitalmars-d]

On Tuesday, 29 August 2017 at 16:25:33 UTC, Jonathan Marler wrote:
> On Tuesday, 29 August 2017 at 05:10:25 UTC, bitwise wrote:
>> [...]
>
> I'm confused, C# has the same problem with events.  They are 
> delegates which under the hood have 2 pointers, a pointer to 
> the method and a pointer to an instance of the object.  How 
> would that be different than if you used delegates in your D 
> library?

You're right that a D event would also incur the same cost for 
adding a delegate to an event. However, there are additional cost 
and problems that come with having the event in a self-contained 
struct that sits in some host object.

1) additional memory cost of a pointer to the event's host object 
if access to a shared mutex, lock, or anything is needed (even if 
no events are attached).

2) additional memory cost of one or more delegates to methods of 
the host object if any special logic is needed to update the host 
object's state in some way when an event is added or removed 
(even if no events are attached). Consider how bad this could get 
when an object needs 4-5, or even more events.

3) inflexibility. It's impossible to satisfy everything that one 
may need with a library implementation, and any attempt at doing 
so would result in an extremely bloated, and still inadequate 
abstraction. For example, @nogc/@safe/etc attributes, choice of 
custom internal container/allocator, signature of callbacks to 
host objects, and I'm sure there's more.

The solution I presented is very simple and easily accounts for 
all of the above stated problems - No memory overhead, direct 
access to host object's members, choice of any attributes or 
event storage you want, straight-forward syntax.