[xinf] Events (was: Re: info for potential new developers)

Mark Winterhalder mark13 at gmail.com
Wed Jun 14 08:30:49 CEST 2006


OK, rather than explaining what I have in mind, I whipped up an
EventDispatcher and attached it. There are some comments in it. Be
warned that it's not tested at all and intended only to describe what
I mean -- it compiles, though. Who knows, it might even work :)

The rationale:

When you look at it, you'll see that you don't subscribe a handler
method, but a handler object that implements EventListener. It must
have a unique ID : String to reference it with, and a method
handleEvent : Event -> Void. If you prefer a handler method for each
event type, you can do listener.handleEvent = this.onMyEvent.
Otherwise use switch inside handleEvent, or have a specific handler
object for each event type.
That's three ways of dealing with events to choose from! Freedom!

Why the unique ID?
I don't like arrays if lists don't have to be ordered, most of all, I
don't like to loop through a potentially large array to find the one
object i want to remove (even if it's hidden beneath Array.remove()).
Subscribing the same listener to the same EventDispatcher for the same
type of event twice wouldn't make any sense, and using a hash table
ensures this can't happen.
Maybe I'm just biased because I like Hash -- in fact, I find it so
useful with unique IDs that I'd be thrilled if there was some neat
built-in thing for unique IDs in haXe...

So, have a look if you like.

Mark

-- 
http://snafoo.org/

key: 1BD689C0 (3801 6F51 4810 C674 1491 ADE7 D8F6 0203 1BD6 89C0)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: EventDispatcher.hx
Type: application/octet-stream
Size: 1650 bytes
Desc: not available
Url : http://xinf.org/pipermail/xinf/attachments/20060614/dbe75824/attachment.obj 


More information about the xinf mailing list