incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cosma Colanicchia <>
Subject Re: Actionscript workers and async locking?
Date Mon, 26 Mar 2012 10:48:28 GMT

> [...] what I'm trying to say is that the perceived simplicity
> of another approach is not such. The entire process is more complex, and
> you cannot reduce it's complexity beyond certain level [...]

I agree - even if I didn't explicitly expressed it, my code sample
just wasn't a real change proposal, rather just a code hint to better
explain what I was talking about. There will be other complexities?
Probably yes - I'd like to have the chance to evaluate them and make a
choice before trashing any alternative approach.

> [...] Well, you shouldn't return anything from an event handler, that's the
> limitation of the system, however it doesn't affect the type check, because
> you don't expect handlers to return anything anyway [...]

Not clear about your answer here. I was talking about the return type
of the async method itself.. any async method (because it is a remote
call, or because it contains a remote call) is now forced to return an
AsyncToken object, thus it cannot have a real return type in its

To make it more clear: if you write a facade/proxy/stub for a
RemoteObject, you can obtain compile-time checking for the method name
and its arguments, but you need to return an AsyncToken, thus no check
on return value (unless you create a lot of AsyncToken wrappers for
each possible return type).

This is also related to another async effect: limited OOP
incapsulation. If you have an object whose external interface is
designed to return a value in a synchronous way, subclasses won't be
able to provide an implementation that is dependent on an asynchronous
invocation (since you can't change the return type signature from the
original type to AsyncToken).

I had to deal with this kind of limitation recently: one of the Flex
OLAP API (crossjoining of two set of tuples) is currently implemented
as a normal, synchronous method. I had to re-implement it using the
green threading approach to support large cubes, thus making it async
in the process: I had to create a different method (instead of
overriding the existing one) and restructure the entire call hierarchy
of the client code to support this new async logic, even if it was
incapsulated behind extendable classes and interfaces. A lot of other
methods need to be refactored as async methods too because they,
directly or indirectly, used the modified version of the method,
because async methods are someway "viral": without a "synchronize"
primitive, they propagate up into the call hierarchy.

> There is yet another concern. Older languages, such as C++ illustrated that
> when you have an API that duplicates another API, the language overall
> becomes more complex and the programmers will become superstitious about
> one kind of the API.

In a general way I share your concerns, but I really don't see any
"duplicated API" here, just a new primitive that could open up a
different approach to a known issue.

> I don't see any benefit of your approach compared to
> what already exists. Having two different approaches is worse then having
> only one in this particular case.

I tried to explain the benefit, I think it is pretty clear: simplified
control flow (expressed by 1 linear method vs a chain of listener
methods referencing each other) and, as positive side effects,
compile-time checking of return values for "resynchronized" methods
and improved OOP abstraction/incapsulation in some async-related


View raw message