--- In flexcoders@yahoogroups.com, "Paul Andrews" <[EMAIL PROTECTED]> wrote:
>
> 
> ----- Original Message ----- 
> From: "Ralf Bokelberg" <[EMAIL PROTECTED]>
> To: <flexcoders@yahoogroups.com>
> Sent: Tuesday, December 09, 2008 3:00 PM
> Subject: Re: [flexcoders] Re: Parsley MVC :: some thoughts
> 
> 
> > Hi Amy
> >
> > Afaik this is not possible in Flashplayer. A block of code is 
always
> > running through without any interuption.
> 
> I think this has been part of the discussion in the thread. While 
it is what 
> I would expect, if dispatching events causes all listening event 
handlers to 
> be called synchronously, it means that any block of code 
dispatching an 
> event is going to be interrupted and potentially "unknown" event 
listeners 
> called during the execution of that code block.
> 
> Here's an interesting scenario:
> 
> If I have a block of code building a data structure and it has an 
object 
> reference to some model. It could be that it encounters some 
situation and 
> dispatches an event. The event handler may then interrogate the 
model, 
> modify the model and control then returns to the executing block 
which is 
> then unaware of the model change and still iterating through the 
model.
> 
> My expectation would be that dispatch event would add the event to 
a queue 
> of events ready to be handled, but those would not be handled until 
the code 
> block had completed.
> 
> In other systems/languages my code blocks would include semaphore 
handling 
> to protect such data structures, but there's no option for me to do 
that in 
> actionscript.
> 
> You may argue that the developer should 'know' what may potentially 
happen 
> when  writing code and despatching events, but in practice who 
knows who may 
> add a new event handler to the application in future and may 
introduce a 
> problem.
> 
> I don't have a problem with all event handlers being called when an 
event is 
> fully despatched, but that's potentially dangerous if it's done in 
the 
> middle of a code block. Anyway it's just a thing to keep in mind. I 
would 
> agree that it's a marginal and unlikely scenario.

Right,  I went back and looked at the code and found that the code 
was calling dispatchEvent.  And then at some point in the code block 
after that (not at the next line, but maybe 2-3 lines later), 
execution would go off to somewhere else that wasn't going to work 
before the other code ran after dispatchEvent.

Reply via email to