I am pretty sure APIs will be enhanced for better lambda use over time but that will probably happen after a 2.8 release.
Given your concrete example it might be cleaner to let fire() return an object that you can use to register callbacks on, similar to a Promise / CompletableFuture. That avoids having lots of overloads of the fire() method with all kinds of parameter combinations. IMHO readability also improves with such an object because it communicates pretty clearly which request state maps to which lambda, e.g. updatingPerson.*onSuccess*(<lambda>), updatingPerson.*onConstraintViolation*(<lambda>). Also you can pass around that instance which can be beneficial and, if supported, possibly attach N callbacks to one request state. -- J. -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/4d40216a-204e-4e77-83a1-d8a00e539eea%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
