Why events if we have delegates

[puzzlecracker]

I took a closer look at delegates and events, and it became apparent
that events don't offer any extra functionalities over delegates. I
don't even see it as syntactical sugar over "overtly obfuscated"
delegate syntax. Moreover, you can accomplish everything with
delegates that you can accomplish with events, such as combining
instances, etc.

Am I missing something here?

Thanks

 

[puzzlecracker]

Yes.  You are missing the fact that if you use a delegate, you are forced  
to use the delegate's mechanism for adding and removing method groups.  If  
you write an event, you have the ability to manage the subscription  
however you like.  For example, the Control class maintains a dictionary  
for each event.  There's a little overhead for the dictionary, but there's  
_zero_ storage for each event unless it's actually subscribed.  For a  
class like Control (and its subclasses) that have a huge number of events 
that are almost never subscribed to, this is a very significant memory  
savings.

Is there a sample implementation of events stored in dictionary to
save memory? It's sounds like an interesting approach, even though
it's unrelated to the question itself, thought it may become clearer
to me when I see the example, a good one.

The other thing you're missing is that an event _encapsulates_ the  
delegate.  That is, while the semantics are similar, only the class  
declaring the event has access to the storage.  Just as with a property,  
code outside the class is forced to go through the accessor methods (add  
and remove for events), and cannot modify the underlying delegate  
directly.  Simply using a delegate would not accomplish this.

So it is meant for a user to prevent exposing the delegate instance to
the event? So events becomes just an anonymous placeholder for a
delegate.

Thanks

 

[qglyirnyfgfo]

Is there a sample implementation of events stored in dictionary to

save memory?  It's sounds like an interesting approach, even though
it's unrelated to the question itself, thought it may become clearer
to me when I see the example, a good one.

I think "Exaple 2" on link http://msdn.microsoft.com/en-us/library/8627sbea(VS.71).aspx

So it is meant for a user to prevent exposing the delegate instance to
the event? So events becomes just an anonymous placeholder for a
delegate.

Create a project where you declare an event and use Reflector to see
what is happening behind the scenes. What you will see is that the
even gets translated into two functions used to add and remove
subscriptions.

That is why you can have event declarations on an Interface, because
behind the scenes, the interface will have a get and set method as the
event definition.

 

[xcal]

delegates are references to methods,
you need some mechanisms to trigger delegates