I agree on your point of custom events being cleaner and easier to follow. In a way, it's like using an Object and defining a class. You can get away with both, and both could be fine. Defining a custom class, although it's some more work upfront, pays off in most cases. Maybe I'm spoiled at this point, but just having the compiler type-checking and auto-completion makes a huge difference. A callback, on the other hand, offers a simpler interface, but it's less self-documenting (now, if you were able to use some kind of typedef's for functions -I think haxe has this feature-, it would be another thing).
I tend to use callbacks especially for onliners or where I don't need much control from the caller (in cases where you just want to signal "this is done" or "this has failed", that sort of thing). I'm not sure I agree about callbacks potentially leading to hard-to-find bugs, though. At the end of the day, Events *are* callbacks. There isn't anything inherintly different in how they work. It's true that most events are dispatched asynchronously (those dispatched by most of the player's APIs), but Events per se are not asynchronous. I found out this the hard way, some time ago, when I had to spend a couple of hours tracking a rare bug in some app I was writting. It took me a while to realized that some function that dispatched an event was being re entered because of a not so obvious side-effect (when the caller received the message, under certain circumstances, it called some code that ended up calling code that ran this function; it was my fault and the code at that point was rather a mess, but I didn't consider the possibility of the function being re-entered because I -mistakenly- though that events were asynchronous; I think I wouldn't have had much problem diagnosing that bug if I were using callbacks in that case). Cheers Juan Pablo Califano 2010/7/27 Kerry Thompson <al...@cyberiantiger.biz> > Henrik Andersson wrote: > > > Custom events are usually overkill. > > If I understand you correctly, Henrik, I disagree. Custom events are > incredibly useful. > > AS3 is event-driven, and I routinely have all sorts of custom events. > In a recent game, I added event listeners to 7 different custom events > in the main class's constructor. When an animation in a MC finishes, > the MC sends the ANIMATION_FINISHED message. When the timer fires, it > sends another message. When the student answers a question, I send > another message. > > I have a class that extends Event, and custom events are defined in > this class. So, when you send a custom event, you get an event object > just as you would with a system event. > > To me, this is a lot cleaner and easier to follow than callbacks or > calls to other methods. It's also less prone to mysterious bugs--when > you call a method, it always returns to the caller. If that caller no > longer exists, you get a crash that can be very hard to diagnose. When > you send a custom message, the code doesn't automatically return to > the sender. > > Or, perhaps I misunderstood your meaning. > > Cordially, > > Kerry Thompson > _______________________________________________ > Flashcoders mailing list > Flashcoders@chattyfig.figleaf.com > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > _______________________________________________ Flashcoders mailing list Flashcoders@chattyfig.figleaf.com http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
