Why Pass EventArgs In Delegate When not needed?

[Phill]

All the event handlers seem to pass an Object and an EventArgs object.
If the event doesn't need this info why pass them anyway? It is inefficient.

[Mattias Sjögren]

All the event handlers seem to pass an Object and an EventArgs object.
If the event doesn't need this info why pass them anyway? It is inefficient.

It's consistent with other event signatures and the .NET design
guidelines.

http://msdn.microsoft.com/library/en...Guidelines.asp
http://msdn.microsoft.com/library/en...Guidelines.asp

It's not like you're wasting significant clock cycles by passing an
extra parameter, especially if you just pass in EventArgs.Empty.

Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Jon Skeet [C# MVP]]

Mattias Sjögren <ma********************@mvps.org> wrote:

All the event handlers seem to pass an Object and an EventArgs object.
If the event doesn't need this info why pass them anyway? It is inefficient.

It's consistent with other event signatures and the .NET design
guidelines.

http://msdn.microsoft.com/library/en...pconEventNamin
gGuidelines.asp
http://msdn.microsoft.com/library/en...pconEventUsage
Guidelines.asp

It's not like you're wasting significant clock cycles by passing an
extra parameter, especially if you just pass in EventArgs.Empty.

Unfortunately I think the convention is somewhat broken. For anything
that really uses a subclass of EventArgs (and let's face it, EventArgs
itself is pretty useless on its own) you want to use a more strongly
typed event handler - such as KeyPressEventHandler. Given that, why
specify EventArgs when there's nothing useful?

I must admit this is one part of the convention that I sometimes break
- I prefer to use

// No more information
void FooEventHandler (object sender);
// Strongly typed information
void BarEventHandler (object sender, BarEventArgs e);

I don't see the point of including a needless parameter - and the fact
that it's there sort of implies that there might be something useful
about it.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

I also agree with Jon, EventArgs is useless. and I also break it all the
time.

One particular escenario when I'd see this happen is when a worker thread
need to signal the UI thread that it's done. All it needs is a method that
is executed in the main thread, it does not matter the sender, and even less
an arg.
Fortunely I think that the anonymous methods in C# 2.0 will solve this.

Cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Mattias Sjögren <ma********************@mvps.org> wrote:

All the event handlers seem to pass an Object and an EventArgs object.
If the event doesn't need this info why pass them anyway? It is

inefficient.
It's consistent with other event signatures and the .NET design
guidelines.

http://msdn.microsoft.com/library/en...pconEventNamin
gGuidelines.asp
http://msdn.microsoft.com/library/en...pconEventUsage
Guidelines.asp

It's not like you're wasting significant clock cycles by passing an
extra parameter, especially if you just pass in EventArgs.Empty.

Unfortunately I think the convention is somewhat broken. For anything
that really uses a subclass of EventArgs (and let's face it, EventArgs
itself is pretty useless on its own) you want to use a more strongly
typed event handler - such as KeyPressEventHandler. Given that, why
specify EventArgs when there's nothing useful?

I must admit this is one part of the convention that I sometimes break
- I prefer to use

// No more information
void FooEventHandler (object sender);
// Strongly typed information
void BarEventHandler (object sender, BarEventArgs e);

I don't see the point of including a needless parameter - and the fact
that it's there sort of implies that there might be something useful
about it.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Rachel Suddeth]

Isn't it because events are implemented within C# .NET as a multicast
delegate, and therefore are required to all have the same signature? The
EventArgs is intended to be subclassed in case you actually need to pass
data. Sure it causes a little confusion until you're used to it, but there
really isn't a performance penalty in sending an arg that carries no
information.

-Rachel

"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us> wrote
in message news:u8**************@TK2MSFTNGP09.phx.gbl...

Hi,

I also agree with Jon, EventArgs is useless. and I also break it all the
time.

One particular escenario when I'd see this happen is when a worker thread need to signal the UI thread that it's done. All it needs is a method that
is executed in the main thread, it does not matter the sender, and even less an arg.
Fortunely I think that the anonymous methods in C# 2.0 will solve this.

Cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:MP************************@msnews.microsoft.c om...
Mattias Sjögren <ma********************@mvps.org> wrote:

All the event handlers seem to pass an Object and an EventArgs object.
If the event doesn't need this info why pass them anyway? It is

inefficient.

It's consistent with other event signatures and the .NET design
guidelines.

http://msdn.microsoft.com/library/en...pconEventNamin
gGuidelines.asp
http://msdn.microsoft.com/library/en...pconEventUsage
Guidelines.asp

It's not like you're wasting significant clock cycles by passing an
extra parameter, especially if you just pass in EventArgs.Empty.

Unfortunately I think the convention is somewhat broken. For anything
that really uses a subclass of EventArgs (and let's face it, EventArgs
itself is pretty useless on its own) you want to use a more strongly
typed event handler - such as KeyPressEventHandler. Given that, why
specify EventArgs when there's nothing useful?

I must admit this is one part of the convention that I sometimes break
- I prefer to use

// No more information
void FooEventHandler (object sender);
// Strongly typed information
void BarEventHandler (object sender, BarEventArgs e);

I don't see the point of including a needless parameter - and the fact
that it's there sort of implies that there might be something useful
about it.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Jon Skeet [C# MVP]]

Rachel Suddeth <ra****@bldhound.com> wrote:

Isn't it because events are implemented within C# .NET as a multicast
delegate, and therefore are required to all have the same signature? The
EventArgs is intended to be subclassed in case you actually need to pass
data.
Except not all events *do* have the same signature. Every delegate
which actually carries real information has a different signature, such
as:

public delegate void KeyPressEventHandler(
object sender,
KeyPressEventArgs e
);

Note that you can't use a "compatible" delegate - you can't declare all
your methods with

public void Foo(object sender, EventArgs e)

and then do

....KeyPress += new KeyPressEventHandler (Foo);

because Foo doesn't have the same signature.
Sure it causes a little confusion until you're used to it, but there
really isn't a performance penalty in sending an arg that carries no
information.

There's a readability penalty though - it implies there's information
there when there isn't.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

"Rachel Suddeth" <ra****@bldhound.com> wrote in message
news:ud*************@TK2MSFTNGP12.phx.gbl...

Isn't it because events are implemented within C# .NET as a multicast
delegate, and therefore are required to all have the same signature?
For a particular event yes, not for all events. Each event may(and do) has
its particular signature
The
EventArgs is intended to be subclassed in case you actually need to pass
data. Sure it causes a little confusion until you're used to it, but there
really isn't a performance penalty in sending an arg that carries no
information.

That is part of the problem. as you MUST subclass EventArgs you cannot use
the same signature for all events. hence the pointless of having EventArgs
in the first place to indicate an event with no parameters.

It does not have any big performance penalty , but here we are talking
about design , theory if you want :) .

What strikes me now , that we are talking about it is that it seems that MS
decided to adopt two different approach in the suggested event signature,
you have the sender, which being an object you must cast it to a particular
type if you want to use it for something, even as I believe it's less used
than EventArgs. But instead of using the same approach for the data
associated with the event ( using an object instance ) it create a new base
class for that, base class that I find have no more use that object in the
same place.

It does have its logic , the sender can be anything, so you can't do
anything else that makes it an object and delegate the responsability to
casting or determine the type to the implementators of the handler. but the
same may apply to the data object. in this case what I would have done is
create an EventArgs class too, but I would make it abstract . this will make
prevent the creation of instances of it.
Now that I finished the message I think that somehow I forget what I was
thinking when I started it and what I was going to say :) It's mid morning a
nd I need caffeine , I will make an expresso to wake me up :D

Cheers,
--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

[Rachel Suddeth]

Thanks, I see (sort of.)

I had this picture of some part of the supporting structure doing something
generic with everything that took an Object & and Eventargs and no return,
but obviously that's not the case since you can do it without those and it
works. And I think I do see what you were getting at...

There's so much abstraction here I think I'll never be able to understand
(but patience... I haven't been dealing with long... just seems like by the
time I finally get it, it'll be obsolete, eh?) Nobody shoot me if I miss
dealing with things I could understand like a message loop with a big fat
switch in it ... <sigh> I know this makes working with GUI easier, only
wish I could understand what was going on.

--Rachel

"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us> wrote
in message news:%2****************@TK2MSFTNGP10.phx.gbl...

Hi,

"Rachel Suddeth" <ra****@bldhound.com> wrote in message
news:ud*************@TK2MSFTNGP12.phx.gbl...

Isn't it because events are implemented within C# .NET as a multicast
delegate, and therefore are required to all have the same signature?
For a particular event yes, not for all events. Each event may(and do)

has its particular signature

The
EventArgs is intended to be subclassed in case you actually need to pass
data. Sure it causes a little confusion until you're used to it, but there really isn't a performance penalty in sending an arg that carries no
information.
That is part of the problem. as you MUST subclass EventArgs you cannot

use the same signature for all events. hence the pointless of having EventArgs
in the first place to indicate an event with no parameters.

It does not have any big performance penalty , but here we are talking
about design , theory if you want :) .

What strikes me now , that we are talking about it is that it seems that MS decided to adopt two different approach in the suggested event signature,
you have the sender, which being an object you must cast it to a particular type if you want to use it for something, even as I believe it's less used
than EventArgs. But instead of using the same approach for the data
associated with the event ( using an object instance ) it create a new base class for that, base class that I find have no more use that object in the
same place.

It does have its logic , the sender can be anything, so you can't do
anything else that makes it an object and delegate the responsability to
casting or determine the type to the implementators of the handler. but the same may apply to the data object. in this case what I would have done is
create an EventArgs class too, but I would make it abstract . this will make prevent the creation of instances of it.
Now that I finished the message I think that somehow I forget what I was
thinking when I started it and what I was going to say :) It's mid morning a nd I need caffeine , I will make an expresso to wake me up :D

Cheers,
--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

[Ignacio Machin \( .NET/ C# MVP \)]

Hi rachel,

If you keep around here reading you will learn ALOT , I learn something
almost daily.

btw , the big fat switch is still around , it's just that you do not see it
anymore :)

Cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
"Rachel Suddeth" <ra****@bldhound.com> wrote in message
news:O9*************@TK2MSFTNGP09.phx.gbl...

Thanks, I see (sort of.)

I had this picture of some part of the supporting structure doing something generic with everything that took an Object & and Eventargs and no return, but obviously that's not the case since you can do it without those and it
works. And I think I do see what you were getting at...

There's so much abstraction here I think I'll never be able to understand
(but patience... I haven't been dealing with long... just seems like by the time I finally get it, it'll be obsolete, eh?) Nobody shoot me if I miss
dealing with things I could understand like a message loop with a big fat
switch in it ... <sigh> I know this makes working with GUI easier, only
wish I could understand what was going on.

--Rachel

"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us> wrote in message news:%2****************@TK2MSFTNGP10.phx.gbl...

Hi,

"Rachel Suddeth" <ra****@bldhound.com> wrote in message
news:ud*************@TK2MSFTNGP12.phx.gbl...

Isn't it because events are implemented within C# .NET as a multicast
delegate, and therefore are required to all have the same signature?
For a particular event yes, not for all events. Each event may(and do)

has

its particular signature

The
EventArgs is intended to be subclassed in case you actually need to pass data. Sure it causes a little confusion until you're used to it, but there really isn't a performance penalty in sending an arg that carries no
information.

That is part of the problem. as you MUST subclass EventArgs you cannot

use

the same signature for all events. hence the pointless of having EventArgs in the first place to indicate an event with no parameters.

It does not have any big performance penalty , but here we are talking
about design , theory if you want :) .

What strikes me now , that we are talking about it is that it seems that MS

decided to adopt two different approach in the suggested event

signature, you have the sender, which being an object you must cast it to a

particular

type if you want to use it for something, even as I believe it's less used than EventArgs. But instead of using the same approach for the data
associated with the event ( using an object instance ) it create a new

base

class for that, base class that I find have no more use that object in the same place.

It does have its logic , the sender can be anything, so you can't do
anything else that makes it an object and delegate the responsability to
casting or determine the type to the implementators of the handler. but

the

same may apply to the data object. in this case what I would have done is create an EventArgs class too, but I would make it abstract . this will

make

prevent the creation of instances of it.
Now that I finished the message I think that somehow I forget what I was thinking when I started it and what I was going to say :) It's mid

morning a

nd I need caffeine , I will make an expresso to wake me up :D

Cheers,
--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation