At a quick glance, something like this seems way better than a wholesale sync->async rewriter.
It's actually important not to hide genuine asyncrony from the developer, because it represents an actual app state the developer should account for (e.g. what UI should be disabled while an async operation is pending? do you show a "please wait" or not?). What we'd want is a framework that makes it easier to produce and reason about necessarily async patterns. On Mon, Nov 2, 2009 at 12:42 PM, Matt Mastracci <[email protected]>wrote: > > The API is just a skeleton to experiment with all the strong-typing > that would go along with porting Oni to Java, so there's not much > there. It helped prove that the concept was sound if I had a chance to > take a go at it and gave me some code to look at while planning it > out. There's still a some porting work to take the Oni code and Java- > fy it. > > I think this is the right first step - once you have a solid async > library like this, there are some interesting things you can build on > it (as Stratified JavaScript builds on Oni: > http://www.croczilla.com/blog/17) > . > > On 2-Nov-09, at 6:17 AM, Bart Guijt wrote: > > > Just checked out Oni - interseting indeed, could have used something > > like that in several recent GWT projects I did. > > > > You mentioned you roughed out an equivalent GWT API - is it publicly > > accessible? > > > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
