events like prioperties

[puzzlecracker]

I am sort of confused here. Jon Skeet allegedly claims that evens are
like properties. To me, on the contrary, they look more like
instances of delegates.

What's the deal here?

Thanks

[Jon Skeet [C# MVP]]

Re: events like prioperties

puzzlecracker <ironsel2000@gm ail.comwrote:

I am sort of confused here. Jon Skeet allegedly claims that evens are
like properties. To me, on the contrary, they look more like
instances of delegates.
>
What's the deal here?

They're like properties in that the events themselves don't allocate
any storage - they're just the add/remove pair of methods, just like
properties are the get/set pair of methods. However, also like
properties, events tend to have a variable backing the event. C# allows
a simplified syntax of:

public event EventHandler Foo;

which declares both an event *and* a variable - within the class, using
"Foo" refers to the variable; outside the class it refers to the event.
Outside the class there is still no direct access to the variable
though.

--
Jon Skeet - <skeet@pobox.co m>
Web site: http://www.pobox.com/~skeet
Blog: http://www.msmvps.com/jon.skeet
C# in Depth: http://csharpindepth.com

[Peter Duniho]

Re: events like prioperties

On Sun, 05 Oct 2008 13:12:36 -0700, puzzlecracker <ironsel2000@gm ail.com>
wrote:

I am sort of confused here. Jon Skeet allegedly claims that evens are
like properties. To me, on the contrary, they look more like
instances of delegates.
>
What's the deal here?

You're both right.

But, as is usually the case when comparing something Jon says to something
any of the rest of us say, Jon is "more right". :)

In particular, what you are looking at is automatically-generated events.
When you declare an event without an implementation, the compiler provides
the implementation for you. Inside the class in which the event is used,
the event looks like a delegate, because that's exactly what the compiler
provides for you (*).

But, behind the scenes the compiler is also adding methods to support the
event. And literally, an event _always_ consists of exactly two methods:
an "add" method and a "remove" method. The field in which the delegate is
stored is implicitly created by the compiler for auto-generated events,
but it's not a mandatory part of an event; only the "add" and "remove"
methods are (you could explicitly implement an event that managed the
subscription to the event in some way other than a simple delegate field).

So, in the same way that the thing that defines a property is the presence
of the "get" and "set" methods (optionally omitting one or the other), the
thing that defines an event is the presence of the "add" and "remove"
methods (though for events, they are not optional). This is what Jon
means when he says events are like properties.

Pete

(*) There are interesting side-effects to this auto-generated behavior:

-- When you take advantage of the auto-generated event, from inside
the class you do _not_ have access to the implementation of the event.
This is normally not an issue, but it means that even though the default
implementation of an event provides for thread-safe access to the event
field, modifying the event field from within the class in that case could
result in a corrupted event because that doesn't go through the accessors.

-- The compiler is required to use the containing object ("this") when
locking for instance events and the type object for static events. In
both cases, this means that the lock is taken using a public reference,
which is usually considered a bad idea: in general, it means that other
code could be locking on the same object at the same time, increasing the
chance of deadlock, and at a minimum increasing contention for the lock.
Fortunately, for an event there's not any subsequent locking that takes
place within the add and remove methods, and so the event should not in
and of itself be able to lead to deadlocking. But I find it interesting
to note the exception to the rule being implicitly expressed in the C#
spec. :)

[puzzlecracker]

Re: events like prioperties

On Oct 5, 4:38 pm, Jon Skeet [C# MVP] <sk...@pobox.co mwrote:

puzzlecracker <ironsel2...@gm ail.comwrote:

I am sort of confused here. Jon Skeet allegedly claims that evens are
like properties. To me, on the  contrary, they look more like
instances of delegates.

>

What's the deal here?

>
They're like properties in that the events themselves don't allocate
any storage - they're just the add/remove pair of methods, just like
properties are the get/set pair of methods. However, also like
properties, events tend to have a variable backing the event. C# allows
a simplified syntax of:
>
public event EventHandler Foo;
>
which declares both an event *and* a variable - within the class, using
"Foo" refers to the variable; outside the class it refers to the event.
Outside the class there is still no direct access to the variable
though.
>
--
Jon Skeet - <sk...@pobox.co m>
Web site:http://www.pobox.com/~skeet 
Blog:http://www.msmvps.com/jon.skeet
C# in Depth:http://csharpindepth.com

Other then being able to use events as properties, is there something
you can do with events that you cannot do with
delegates?

Take a look here:

delegate string MyDelegateHandl er(int x);

class ServicingToEven ts{

public event MyDelegateHandl er handler;

onMyDelegateHan dler(int x){
if(handler!-null)
handler(x);
}
protected void DispatchEvents( )
{
int i;
//read
onMyDelegateHan dler(i);
}
}
class ServicingToDele gates{

public MyDelegateHandl er handler;

onMyDelegateHan dler(int x){
if(handler!-null)
handler(x);
}
protected void DispatchEvents( )
{
int i;
//read
onMyDelegateHan dler(i);
}
}


class EntryPoint{
{
static void Main(string[] args)
{

ServicingToEven ts ste=new ServicingToEven ts();
ste.handler += MyHandler;

ServicingToDele gates std=new ServicingToDele gates();
ste.handler=new MyDelegateHandl er(MyHandler);
}
public static MyHandler(int x)
{

System.WriteLin e("{0} is received")
}

}


I don't see the clear difference between these two beasts, other than
events give more typing convenience.

Please explain.

Thanks

[Peter Duniho]

Re: events like prioperties

On Sun, 05 Oct 2008 14:56:22 -0700, puzzlecracker <ironsel2000@gm ail.com>
wrote:

Other then being able to use events as properties,

Careful with your language there. Events behave similarly to properties,
but you cannot "use events as properties".

is there something
you can do with events that you cannot do with
delegates?

In the same way that properties allow you to abstract away the
implementation from the behavior, so too do events. At a minimum, just
like a property allows you to hide the actual storage, preventing outside
code from accessing it without going through your accessors (which allows
you to do things like lazily instantiate the value, raise an event, update
the UI, log something to disk, validate the value, etc. when the property
is accessed, without worrying that the event might be accessed without
your code being involved).

But also like properties, it allows for a more-complex implementation of
the event itself. For example, the Control class uses a dictionary to
keep track of all the events that have actually been subscribed. There
are so many events in a Control, and so few of them are ever actually
subscribed at any given time, that by not even storing a null reference
for those events that aren't subscribed, a significant memory savings is
had.

Basically, it's an abstraction in the same way that properties are, and
with the same kinds of advantages.

Pete

[Jon Skeet [C# MVP]]

Re: events like prioperties

On Oct 5, 10:56 pm, puzzlecracker <ironsel2...@gm ail.comwrote:

Other then being able to use events as properties, is there something
you can do with events that you cannot do with
delegates?

I never said you could use events as properties. I merely said they
were *like* properties in that they basically represent a pair of
methods.

The benefit of using events instead of public delegate variables is
the same as the benefits of using properties instead of public
variables in general - it gives you more control.

With events, only the ability to subscribe/unsubscribe is exposed -
clients can't raise the event, or set the variable to some arbitrary
delegate (effectively removing any other handlers which have
subscribed). Likewise you can also put in your own add/remove logic,
if you want to use a different storage mechanism (e.g.
EventHanderList ).

If you haven't read http://pobox.com/~skeet/csharp/events.html I
suggest you do so. You may well have read it already though - I
wouldn't be surprised if it were that article which prompted the
question.

Jon