What you're describing is formal support for continuations in the compiler. While I'm sure this is theoretically tractable, there are several practical issues that are likely to be problematic. The first is simply that it makes an asynchronous look synchronous, which is nice on the surface, but can hide very subtle bugs that are much more clear when the asynchrony is explicit. Imagine the following case:
Data data = service.getSomeData(); // code really returns here, and perhaps in several hundred ms calls the following: showDataInUi(data); There's nothing obvious to indicate to the developer that it is necessary to deal with the intermediate UI state -- data has been requested, and will be shoved into the UI in "a while". What should I do to the UI to indicate this state? Should I display a "loading..." box somewhere? Should I disable UI elements that might allow the user to navigate away from the part of the UI that will be used to display the results? What happens if showDataInUi() is called, but the UI's no longer there? These are all important questions to think of, and obscuring the async nature of the call makes it all the more likely that developers will ignore them. The second problem is that it makes the potential error states even less obvious. I suspect an onFailure() could be transformed into a normal exception, but it would be even less obvious to the developer than it currently is that it's likely to happen. Finally, there's the implementation issue, that a stack frame cannot be "resumed" in Javascript as it can in other languages/VMs with formal continuation support (c.f. http://en.wikipedia.org/wiki/Call-with-current-continuation). I believe this will lead to subtle changes in behavior that will be very surprising in practice. On Mon, Aug 3, 2009 at 5:36 AM, jd <jdpatter...@gmail.com> wrote: > > I can see that allowing the above would still not solve the async, > single threaded nature of ajax calls. > > But there must be some way to reuse the Service interface on the > client. > > Perhaps compiling a call to a Service interface could be implemented > in JavaScript like this: > > Java: > StockPrice[] prices = stockPriceSvc.getPrices(); > Window.alert("first bit done"); > try { > MyResult result = anotherService.doSomehingWithPrices(prices); > Window.alert("all done" + result); > } > catch (RemoteException re) { > Window.alert("Oops " + re.getMessage()); > } > > JavaScript: > function firstBit() { > callAsync("stockPrice", secondBit); > } > > function secondBit(var prices) { > alert("first bit done"); > try { > callAsync("anotherService", thirdBit); > } > catch (e) { > alert("Opps + e.description); > } > } > > function thirdBit(var result) { > alert("all done" + result); > } > > > This would give the appearance of multi-threaded code. > > I am interested to hear why this would never work in practice ;) > > Cheers, > > JD > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
