Re: JsInterop @JsFunction is not really a function?

(It looks like I forgot this email in my drafts.)

As of https://gwt-review.googlesource.com/#/c/12810/ this should be fixed.

On Tue, Apr 14, 2015 at 4:40 AM, Marcin Okraszewski <okrasz@gmail.com> wrote:

The document you posted is very interesting. Is there any place that would tell what is implemented out of it?

I understand the problem with call() and apply(), as these are used to specify what object will be visible as "this". I cannot think about corresponding concept in Java. I don't know how that should be solved, but without it, it is very difficult to say we have a seamless integration with JS world. Maybe there should be always passed "this" as first parameter? It wouldn't be very natural, but at least gave a way to work with it.

Thank you,

Marcin

On Tuesday, 14 April 2015 11:56:23 UTC+2, Jens wrote:

Maybe Goktug can say something about it.

The spec document [1] has quite a bit of information about SAM handling however @JsFunction isn't directly mentioned yet and the implementation of @JsFunction is actually a bit different. I am pretty sure @JsFunction should somehow behave like a real function because you never know how a JS library will execute a callback. It would indeed hurt interoperability if callback.apply and callback.call can't be called by a JS lib, e.g. JQuery, to run the SAM method as you pointed out.

However as the spec document points out SAM handling is a bit more complicated as the lambda expression might get passed back to Java and then should behave as Java again.

[1] https://docs.google.com/document/d/1tir74SB-ZWrs-gQ8w-lOEV3oMY6u6lF2MmNivDEihZ4/edit

-- J.

Am Donnerstag, 9. April 2015 14:31:19 UTC+2 schrieb Marcin Okraszewski:

Hi Jens,

Thanks for answering again :) 

I just wonder - if this is intended, how should I then pass callback to JS functions? I was doing similar jQuery example as was presented on "Deep dive in JS Interop" persentation - https://www.youtube.com/watch?feature=player_embedded&v=-s4Wfnojh1Q#t=200 . My even simplified version. And this is failing. For me if the @JsFunction doesn't fully behave like a function, it doesn't fulfill the premise and the integration with JS will be a bit harder. I hope it is just not yet finished. 

@JsType(prototype = "jQuery")

public interface JQuery {

JQuery css(String attr, String value);

JQuery click(Callback callback);

}

@JsFunction

public interface Callback {

void callback();

} 

static native JQuery jquery(String selector) /*-{

return $wnd.jQuery(selector);

}-*/;

 

// ...

jquery("button").click( () -> Window.alert("Click!") );

Marcin

On Thursday, 9 April 2015 13:45:00 UTC+2, Jens wrote:

Hmm not 100% sure but it looks intended.

How the @JsFunction is implemented in the AST: 

https://gwt-review.googlesource.com/#/c/11960/8/dev/core/src/com/google/gwt/dev/jjs/impl/GenerateJavaScriptAST.java

How the Javascript function is generated that wraps the call to your @JsFunction Java SAM method: 

https://gwt-review.googlesource.com/#/c/11960/8/dev/core/super/com/google/gwt/dev/jjs/intrinsic/com/google/gwt/lang/JavaClassHierarchySetupUtil.java

So you can see the generated javascript function is calling the SAM method by providing itself as "this" (using samMethod.call(lambda, ..) ) and the proto is set to the Foo instance that has the samMethod defined.

-- J.

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.