On Fri, May 29, 2009 at 11:59 AM, John Tamplin <[email protected]> wrote:
> On Fri, May 29, 2009 at 11:31 AM, Vitali Lovich <[email protected]> wrote: > >> The way you get a method reference in pure Java is via reflection, which >>> in general is not feasible though there have been some discussions of >>> allowing it when everything can be evaluated at compile time (ie, all >>> constants for classes and method/field names) -- even that seems to be a >>> long way away however. >>> >> How about through GWT.create? Then it uses reflection to supply the >> actual function. Might be limited to JSNI functions unless you can compile >> code fragments. >> >>> > GWT.create takes a single class literal, so there is no way to describe a > method. You could have it generate an object with a callback function, but > that is going to be a lot more boilerplate than just having a simple JSNI > method that returns the torn-off function. > > Not necessarily GWT.create - just something along those lines that provides enough static information for it to resolve the method yet also provide compile-time checking for that. I'm still thinking about it - it is difficult to think of a clean way of doing it (without the boilerplate code as you mentioned) since overloading is what causes problems. > I haven't actually looked at the plugin yet. >> > > If you are worried about JSNI syntax or autocompletion, you really should. > You also get a "Deploy to Google" button for AppEngine integration. > I'm not actually - it would just be nice to not have to drop into JSNI for something that is seemingly so simple. > > > >> Why not create a JsFunction class that extends from JavaScriptObject to >> represent a JS lambda function. >> >> However, since you can't have polymorphic dispatch on JSOs, that would >>> reserve whatever name was chosen from all subclasses, so it would have to be >>> something unlikely to collide. >>> >> >> I'm not sure what you mean here. Why would you need to reserve a name? >> > > Because of how JSOs work (in that you can freely cast them to each other), > JSO method calls have to be statically resolvable. If we put a call() > method on JavaScriptObject, no other JSO subclass could have a call method > with the same signature (and that restriction is enforced by requiring the > method or class to be final). However, your suggestion of putting it on a > JSO subclass solves that problem. > > The remaining complication is that you can't declare a JSNI method with > varargs, so it is somewhat complicated to build the args list for the call. > You would probably also have to have one for void returns and one for calls > returning a value (it might be possible to handle that with a return type > parameter on JsFunction like JsFunction<Int>). > Yeah - the varargs is the problem. I was thinking about maybe using eval, but I can't really see how. I concede that there's probably no way to do all this cleanly within the context of GWT (at least not without ugly hacks that break Java syntax). > > > -- > John A. Tamplin > Software Engineer (GWT), Google > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
