I seriously don't know... I see all these "solutions" as attempts at fixing
something that isn't broken, so I wouldn't use any because, frankly, I
think that evens / event dispatcher is a more generic, more simple to use
and more idiomatic way to do this in Flash. Why on earth do you want to do
something instead of it?
This reminds me of how almost every newcomer to Lisp tries to come up with
some reader macros that allows use of infix operators, because newcomers
are annoyed about that math isn't written precisely the same as it appears
in their textbooks (+xy instead of x+y). It is possible to do, but is a
waste of time. It's something that the said enthusiastic programmer will
abandon in a couple of months and will never use again.
To continue the illustration of the example with errors: what if you were
using a socket, where errors are fine some times, but they don't happen as
often as you receive data. Besides, you may receive plenty of different
errors and plenty of different messages, which you don't want to handle all
in one place. If you will try to make it linear, you'll end with something
like this:
for (...) {
try { message = socket.readMessage(); }
catch (error0:IOError) { /* handle IOError */ }
catch (error1:SecurityError) { /* handle SecurityError needs to use some
code from IOError clause, ouch! */ }
catch (error2:ParsingError) { /* handle ParsingError */ }
/* here you already don't know what to do with the message and whether you
didn't get here by mistake */
}
This is a typical Java-style mess. What if two errors happened at the same
time? Why would anyone want this instead of having handlers?
EventDispatcher offers you an abstraction, something that spares you
writing the for loop and implementing complex interoperability of different
handlers you would otherwise create ad hoc in every function of the similar
nature.
Best.
Oleg
