incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Taylor Brown <>
Subject Re: Actionscript workers and async locking?
Date Mon, 26 Mar 2012 12:12:53 GMT
Have you all seen this "Promises" AS3 api?

I just discovered it, but it looks pretty darn nice.

@Cosma, your initial "locking" code example reminds me of the new "await"
keyword in C#:

This also reminds me of "Reactive Extensions", which was a library that
attempted to address some of the issues with asynchronous spaghetti. It was
originally a .NET project, but it's been ported to AS3. (AS3
Implementation: It's been a while
since I looked at it, but I recall that reactive programming was an
interesting way of looking at asynchronous code. Although I remember it
making some things easier to read, the learning curve was steep (to my mind
anyway), and the end result didn't feel particularly readable. @Justin
mentioned the problem of having 3 separate calls that need to return before
the 4th call can be made, and that is one of the things that I recall
Reactive Extensions could solve specifically. In fact, Reactive Extensions
were specifically good at taking multiple asynchronous streams of results
and combining them in different ways.

I wrote a library to make it easier to write pseudo/cooperative "threads"
in AS3:
It's good at splitting it up a task so that it runs like a background
thread that still reads linearly. (Granted, this will be obsolete once
worker threads get here). After reading about all of these asynchronous
concepts again though, it makes me want to revisit my library and express
some of the API in terms of Promises. I think it would simplify things a
great deal.


Taylor Brown

On Mon, Mar 26, 2012 at 1:11 PM, Cosma Colanicchia <>wrote:

> @Martin
> > A DSL for lazy operations has proven itself quite valuable as you can se
> > from the various tweening apis they may be a little wasteful but
> > ultimately result in more stable, flexible systems that are easier to
> read.
> In alternative to "real" synchronized methods, I agree that a powerful
> DSL for lazy operations would be really useful... this could also be
> more in line with the current async approach.
> Cosma

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message