(no subject)

[bellwether]

The weekend was long and emotional. 45 hours of Engaged Encounter make for a very tired Kevin. As morganlf has mentioned, it was quite long, quite tiring, and often quite silly. The Irish priest was the best part though, especially when he started in on the mother-in-law jokes. :)

Today has been mostly uneventful--coding and working on my qual presentation. Anyone know anything about extensible event dispatch in Java? I need a good data structure to represent arbitary EventReceivers (objects implementing an EventReceiver interface) who are interested in different types of events (all subclassing a common Event class). In the past I've created a Vector per event type to represent all interested EventReceivers and then notified all the Vector elements when an incoming event matches. This isn't very extensible though, since as I add new event types to the system I have to create more recipient vectors, etc. I'd also like to be able to match on internal event structure, although I'm worried about associated overhead....

Anyone done anything like this? Read papers on a similar topic? Point me at them! :)

Comments

[minorninth.livejournal.com]

Inspired by wxWidgets, I'd recommend something like this:

1. Create an enum of all possible event types. Each one of these is associated to a subset of the Event class in a many-to-one relationship. In other words, you don't need a separate Event class for every possible event. wxWidgets has hundreds of different events, but only a dozen or so classes. Almost all events generate a CommandEvent, for example.

2. Each class that is capable of sending events has a method, RegisterEventReceiver(enum EventType, EventReceiver). It can simply build an array of event queues based on the max size of the enum.

This is a very simple system but very easily extensible - especially once you realize that most new event types you create will probably not require new Event subclasses. The only potential flaw here is that it is never enforced that someone who sends an event of type X has to actually pass around the corresponding Event subclass.

Honestly, if I was going to implement this for my own use, I'd get rid of the enums and use a String for the event type, and have the event queues in a hash. It's a very Pythonesque way of doing things. I know that there's the small worry about spelling errors and such, but 1) the code would never crash, the worst case scenario is that events wouldn't get received, and 2) a simple shell script could help you find all of the event types in your code, sort them and count the number of occurrences of each. Misspellings or typos would totally jump out at you.

Hope this helps.

[bellwethr.livejournal.com]

It did help! Thanks.

I decided to use a hybrid approach of your suggestions -- I'm using a Enum of event types for a small (order 10) number of base event types that my system will use internally, and for application-extensible events, I'm using a Hashtable of that maps a String-based key to a Vector of interested recipients.... it seems like a reasonable compromise, and will allow applications to create their own event types if they like. Thanks again!

[robbbbbb.livejournal.com]

How was the Engaged Encounter event? I'm headed to one in Seattle in a couple of weeks, and I have no idea what to expect.

[bellwethr.livejournal.com]

It was long and emotional. Ours was structured as a series of sessions where two married couples and a priest talked with us about a huge number of topics for about 30-40 minutes. Then we'd break apart and write individually, answering a series of questions about our relationship, our personal views, etc. After 20 minutes of writing, we'd get back together with our respective fiancees and discuss our answers. Now imagine doing this for 14 hours straight! That was my Saturday.

Overall, it was good. We got an opportunity to really think about a number of issues we'd discussed before somewhat superfluously.