Events in D

bitwise via Digitalmars-d digitalmars-d at puremagic.com
Thu Aug 31 14:10:24 PDT 2017


On Thursday, 31 August 2017 at 19:36:00 UTC, kinke wrote:
> On Wednesday, 30 August 2017 at 15:35:57 UTC, bitwise wrote:
>> -What if I want an event to lock a shared mutex of the 
>> enclosing object, without storing a pointer to that mutex 
>> inside the event itself (and every single other event in the 
>> object)?
>>
>> -What if I want an event to call a method of the enclosing 
>> object when a handler is added (without keeping a pointer to 
>> it inside the actual event)?
>
> So in essence, you'd like something like this to work, right?
>
> struct Event(alias __parent, Handler) {
>     enum parentHasLock = __traits(compiles, __parent.lock());
>     ...
>     void opCall()(Parameters!Handler args)
>     {
>         static if (parentHasLock)
>             __parent.lock();
>         ...
>     }
> }
>
> struct Host1 {
>     Event!Handler onChanged;
>     Event!Handler onClosed;
> }
>
> and have the compiler internally instantiate something like
>
> Event!(/* parent type */ Host1, /* .offsetof in parent in order 
> to deduce the __parent address from Event's &this */ 0, Handler)
> Event!(Host1, N, Handler)

Something like that ;)

I played around with this idea while trying to create a library 
implementation of properties for C++. `offsetof` in C++ is unsafe 
though, which I think was due to how multiple inheritance works. 
It was only recently allowed by the standard, with limitations 
that make it all but useless:

See restrictions on "standard layout class"
http://www.cplusplus.com/reference/cstddef/offsetof/

IMO though, this path is still fraught with peril, even if it 
works in D. The declaration of an event would have to be very 
noisy, and full of extra template parameters that only existed to 
supplement the underlying hack. And it still wouldn't allow 
invocation of host object code, without even more painful bloat.



More information about the Digitalmars-d mailing list