Why Pass EventArgs In Delegate When not needed?

  • Thread starter Thread starter Phill
  • Start date Start date
P

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.
 
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.
Click to expand...

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

http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconEventNamingGuidelines.asp
http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconEventUsageGuidelines.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 said:
It's consistent with other event signatures and the .NET design
guidelines.

http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconEventNamin
gGuidelines.asp
http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconEventUsage
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.
Click to expand...

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.
 
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



Mattias Sjögren said:
inefficient.

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

http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconEventNamin
gGuidelines.asp
http://msdn.microsoft.com/library/en-us/cpgenref/html/cpconEventUsage
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.
Click to expand...

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.
 
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
 
Rachel Suddeth said:
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.
Click to expand...

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.
Click to expand...

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

Rachel Suddeth said:
Isn't it because events are implemented within C# .NET as a multicast
delegate, and therefore are required to all have the same signature?
Click to expand...

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.
Click to expand...

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,
 
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
 
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,
 
Back
Top