Function overloading with inherited types

Here is what I want:

Code:

---

interface IEvent
{
  ...
}

class EventType1 : IEvent
{
  ...
}

class EventListenter
{
  public void HandleEvent(IEvent evt)
  {
    ...
  }

  public void HandleEvent(EventType1 evt)
  {
    ...
  }
}

class EventManager
{
  List<IEvent> events;
  EventListener listener;

  public void ProcessEvents
  {
      foreach(IEvent event in events)
      {
        listener.HandleEvent(event);
      }
  }
}

---

So basically I want the EventManager class to call the correct version of the HandleEvent function based on the type of event it is. However it does not. It seems that because the events list contains IEvent objects, it just always calls that version of the HandleEvent function. Even if the specific event is an EventType1, it still calls the more general IEvent version of the function.

I could but in a big if statement to get it to call the right version but I was hoping for something more elegant. Am I missing something?

Thanks.

May I ask what are the differences between IEvent and EventType1 that require different type of handling? The problem you've got is that in your loop is that every 'event' is an 'IEvent' regardless of the concrete type. In your case you've only shown one implementation of 'IEvent'. I'm pretty sure you've got more. You may want to revise your implementation as whole. And if you are really looking for event processing why not go for an approach built around delegates or Events which are built into the framework?

At the moment I only have one type of event but the plan is obviously to have more.

The exact types are yet to be determined but they could be pretty much anything (ButtonPressed, KeyPressed, FrameRendered, ChickenKicked).

I am basically trying to create a generic Event system that I can then use for a variety of purposes.

I prefer this to the built in event system because it gives me better control over when the events get fired and allows me to better track what events are occurring and who is listening to them.

Quote:

---

Originally Posted by Eggman002

I prefer this to the built in event system because it gives me better control over when the events get fired and allows me to better track what events are occurring and who is listening to them.

---

Uhm....I'm sure you know what you're doing. To me it looks like you may be re-inventing the wheel a little bit. I think with the built in model you have control over when an event get's fired. I'm not sure about the options for tracking of events and find out who's listening to them (though I would be surprised if there was nothing built in for the latter...) but do you really need that? Typically when a button is clicked it raises an event 'I've been clicked' to all who would care to know about it. The button doesn't care who knows about it, the different listeners don't need to know about each other (although that might be useful in certain scenarios I guess...Anyway there might be a design pattern that could guide you in accomplishing what want. I would say have a look at some of those. Sorry I can't mention any specific one that is close to what you want at the moment...:)

Quote:

---

Originally Posted by nelo

I think with the built in model you have control over when an event get's fired.

---

You can control when it gets fired in the existing system. But suppose you want a system where all events get fired at the same time. So in my system for example I want to be able to check for events, add them to a queue and then at a specific time empty that queue and process all events. Though you could do this with the existing system, I am pretty sure it would be a huge hassle.

Quote:

---

Originally Posted by nelo

I'm not sure about the options for tracking of events and find out who's listening to them (though I would be surprised if there was nothing built in for the latter...) but do you really need that? Typically when a button is clicked it raises an event 'I've been clicked' to all who would care to know about it. The button doesn't care who knows about it, the different listeners don't need to know about each other

---

In each class you can override the operators which register events. This allows you to add your own tracking mechanism if you want to. However you have to do this for each class and each event type which can get tedious. If there is another way I am not aware of it.

Why would you want to do this? Because in the past I have often found myself in situations where I have registered an event handler, then deleted the object that was listening for the event. However I have forgotten to de-register the event handler. Now we have a memory leak. Because as long as the event handler is active, the garbage collector can not clean up that deleted object. At least that is my understanding. By doing it this way I can see exactly who is listening to events. That way I can look and say "wait, wasn't that guy deleted?". Basically it will make things a bit nicer to debug.

There are other reasons but to prevent this from turning into a novella, I won't list them.

If you are worried about memory leakage, then just use the WeakEventListener pattern. Problem solved.

If you *require* that you know who registers handles for each event, then you should just override the Add/Remove handlers for events and apply your logic there. Users of your library probably just want to see the normal event pattern and not some customised not-quite-event-but-kinda-similar-but-with-subtle-differences system ;)

You can trivially control when an event gets raised and when it doesn't by using the Event + virtual method pattern, which is the standard event pattern.

Quote:

---

Originally Posted by Mutant_Fruit

Users of your library probably just want to see the normal event pattern and not some customised not-quite-event-but-kinda-similar-but-with-subtle-differences system ;)

---

User's of the library consist of me. So that isn't really an issue.

Lets just forget about whether I could use the existing event system or not. As mentioned I have other reasons why I want to do it this way but I don't want to get into a discussion about what the best event handling system is. That isn't the purpose of this thread. For that matter we could even assume I am not talking about events.

What I want to know is whether there is an elegant way to get it to call the correct version of the function given the inheritance structure provided. I would prefer to avoid manually checking the type of the incoming object if possible.

Quote:

---

Originally Posted by Eggman002

What I want to know is whether there is an elegant way to get it to call the correct version of the function given the inheritance structure provided.

---

There is no elegant way.

Code:

---

IEvent e = new EventType1 ();
EventListener listener = new EventListener;
listener.HandleEvent (e);

---

The above code will invoke the HandleEvent(IEvent e) overload and not the HandleEvent(EventType1 e) overload. The decision as to which method should be invoked is performed at compile time and the best matching method is chosen then. In this scenario, there is only 1 option as the compile time type is "IEvent" and only 1 method can accept "IEvent".

If the compile time type was EventType1, then the best matching method would be the method which accepts "EventType1" as that offers an exact type match.

Quote:

---

Lets just forget about whether I could use the existing event system or not.

---

My point was only that if you want an event like system, then use events. There's no need to re-invent the car when you can just change the engine instead ;)

Code:

---

public event EventHandler SomethingHappened {
    add { EventListener.AddHandler (value); }
    remove { EventListener.RemoveHandler (value); }
}

---

You can do whatever you want there, but for users (yourself) everything is still the standard pattern for consumers of the class/event. You can use this technique to make every 'normal looking' event use the WeakEventListener pattern under the hood without requiring your users (yourself) to do anything complex. Similarly you could plug in your custom eventing machinery in there which monitors who registers handlers and all that. The 'value' parameter will have a reference to both the method which will be invoked and the object who 'owns' the handler (i.e. who's listening).

Well stated Mutant_Fruit.

I think Eggman002 was looking for some kind of polymorphic behaviour that would execute the appropriate method. Great tip on the implementing the 'add' and 'remove' on the EventHandler. I had forgotten you could do that.