In response to a couple of the responses so far, please read beyond the pseudo-example. (it's just a simple example of how it might be implemented in theory)
The case below the example describes a recursive situation (traversing the UI hierarchy) where using setTimeout() would be inadequate to wait for SWFLoaders during recursion... And to cover my bases, yes, if you had a recursive function with no other calls/logic that followed, you could maintain your recursive state with an Array/stack and use setTimeout -- however my case always has dependent logic after the recursive function (since it returns a result), and furthermore this function would be a utility for others to use... so I have no control of the code that calls it. Adobe, comments? --- In [email protected], "j.conley" <[EMAIL PROTECTED]> wrote: > > > I was wondering if there are any plans to consider continuation > support in flash/flex? ...predominantly to support the concept of a > smarter "Thread.sleep(n)" without blocking or disrupting the > single-threaded execution model. > > for context, here is a "sleep" pseudo-example using the continuations > concept: > > function example { > trace("before"); > sleep(2000); > trace("after 2 seconds"); > } > > function sleep(sleep_millis:int) { > var savepoint:Continuation = Continuations.new(); // creates a > holder that will capture the execution stack state at the next suspend() > setTimeout(function(event:Event):void { > Continuations.resume(savepoint); // resumes the > saved execution stack > },sleep_millis); > Continuations.suspend(savepoint); > } > > For my purposes, I am writing a general-purpose tool for developers > that would locate one or more components in the UI hierarchy (by some > criteria), then return those components so they could interact with them. > In searching for said components, I have come across embedded > SWFLoaders which are not yet finished loading/reloading, and sleep() > (via continuations) would allow checking it's state periodically and > not disrupt the execution stack, callers code or block the overall > application. > > There are several other cases where this would be useful, but I just > wanted to start a dialog on it. >
