>>> I agree with everything you say, up to that point. There is a fundamental difference in the way callbacks and messages work. A callback puts the caller on the call stack, and control will eventually return to that calling method. A message does not put the sender on the call stack. >>>
Well, that's what happens in most cases, but as I said before, it's not because of how event dispatching works, but rather because most events are dispatched asynchronously (or most events dispatched by the player itself anyway, such as those fired by loaders, mouse interaction, etc). But, my point was that the event dispatching mechanism is not inherently asynchronous. So an event handler could be called just like any other callback. To make my point more clear, consider this code and look the stacktraces it prints out: package { import flash.display.Sprite; import flash.events.Event; public class Main extends Sprite { public function Main():void { runTest(); } private function runTest():void { var callbackTest:Tester = new Tester(); callbackTest.run(callback); var eventTester:Tester = new Tester(); eventTester.addEventListener(Event.COMPLETE,handleComplete); eventTester.run(null); } private function handleComplete(evt:Event):void { trace("entering handler"); var stacktrace:String = new Error().getStackTrace(); trace(stacktrace); trace("returning from handler"); } private function callback(evt:Event):void { trace("entering callback"); var stacktrace:String = new Error().getStackTrace(); trace(stacktrace); trace("returning from callback"); } } } import flash.events.Event; import flash.events.EventDispatcher; class Tester extends EventDispatcher { public function Tester() { } public function run(callback:Function):void { trace("entering run"); if(callback != null) { callback(new Event(Event.COMPLETE)); } else { dispatchEvent(new Event(Event.COMPLETE)); } trace("returning from run"); trace("------------"); } } The results are: entering run entering callback Error at Main/callback()[Main.as:29] at Tester/run()[Main.as:49] at Main/runTest()[Main.as:13] at Main()[Main.as:8] returning from callback returning from run ------------ entering run entering handler Error at Main/handleComplete()[Main.as:22] at flash.events::EventDispatcher/dispatchEventFunction() at flash.events::EventDispatcher/dispatchEvent() at Tester/run()[Main.as:51] at Main/runTest()Main.as:17] at Main()[Main.as:8] returning from handler returning from run ------------ If you factor out the 2 native methods involving in calling the event dispatching (which are there just because of the generic nature of dispatching as opposed to having your callbacks hardcoded), the call stack looks exactly the same both for the direct callback and the event case. Cheers Juan Pablo Califano 2010/7/27 Kerry Thompson <al...@cyberiantiger.biz> > Juan Pablo Califano wrote: > > > 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. <snip > > At the end of the day, Events *are* callbacks. There isn't > > anything inherintly different in how they work. > > I agree with everything you say, up to that point. There is a > fundamental difference in the way callbacks and messages work. A > callback puts the caller on the call stack, and control will > eventually return to that calling method. A message does not put the > sender on the call stack. > > It's entirely possible that you will have obscure bugs using messages. > Even the best of coders will occasionally code him/herself into a > corner. And yes, sometimes a bug involving a message is harder to find > than one involving a callback. That's the exception, though, and not > the rule. Like any job, we go with the percentages, and they're pretty > heavily in favor of messages. > > I do reiterate, though, that custom messages are for > intermediate-level and above programmes. They're not for novices. > Chances are that novices will have some work to do getting their minds > around the concept of messaging. Once you do that, you have unlocked > one of the most powerful features of AS3. > > 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