>>>
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

Reply via email to