@LeftRight: > [...] 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 signature. 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 scenarios. Cosma
