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.
