This content has been marked as final. Show 3 replies
From what i understand yes.
You got it. Flex is event driven - we love events.
Thanks for the confirmation.
I'm fond of events too, but I have to wonder whether the end of an effect is a bit of a non-event.
Events are generally of some significance: a mouse click, a key press, or perhaps some threshold being reached in a game. They trigger a specific sequence of code, and their ocurrence is generally unpredictable, at least at the time you write the program. But an effect, once started, is predictable. It's going to end, and we know when. The only issue about effects is whether we want them to play synchronously or asynchronously. If we want them to play asynchronously, we have little interest in the effectEnd event. But if they always played synchronously, we would treat them much like a function or any single statement, and again wouldn't be interested in an effectEnd event. Wouldn't it be much simpler, from a scripting perspective, to have a way of flagging whether an effect should play synchrnously (like a normal statement), or asynchronously, and leave event handling for meaty events such as mouse clicks or asteroid collisions.
Actually, I came across an example (in another context) of using nested functions as event handlers. I'm not sure whether it's a good solution to my original problem yet. I may just be swapping scattered logic for unreadable logic. But I'll give it a try.