Jens, the issue is not anything to do with ambiguity, it has to do
with the way we are able to treat an anonymous class as both a
function and an object, see Runtime.java makeLambdaFunction
/**
* Create a function that applies the specified samMethod on itself,
and whose __proto__ points to
* <code>instance</code>.
*/
public static native JavaScriptObject
makeLambdaFunction(JavaScriptObject samMethod,
JavaScriptObject instance) /*-{
var lambda = function() { return samMethod.apply(lambda, arguments); }
if (lambda.__proto__) {
lambda.__proto__ = instance;
} else {
for (var prop in instance) {
lambda[prop] = instance[prop];
}
}
return lambda;
}-*/;
What this does is take a Java class, and a reference to it's prototype
method, creating a new function, and seeing its prototype to be the
Class.
This lets you invoke a lambda as both lambda() or lambda.method() in
JS and Java code, it also means stuff like lambda.getClass(),
lambda.hashCode() etc work.
On Tue, May 17, 2016 at 11:13 AM, Jens <[email protected]> wrote:
>
>> The issue is that @JsFunction implementors must "extend
>> java.lang.Object" as their parent. because standard library functions
>> are/canbe implemented on classes with complicated type hierarchies,
>> this would cause failures to compile.
>>
>> This restriction comes about from the efficiency trick we use to
>> reparent a lambda to have the native JS Function object as it's
>> parent. We can't reparent objects whose immediate supertype isn't
>> java.lang.Object, but not doing this trick would make output more
>> bloated/slow, and wouldn't allow Java8 lambas to act like JS functions
>> (e.g. can call Function.bind/apply/etc on them) without some kind of
>> wrapping/unwrapping process, plus an additional level of hacks to make
>> sure referential integrity was preserved.
>
>
> Can you elaborate on it? I think its really annoying that every project must
> redefine callbacks, functions, consumers, whatever just because JRE has some
> default methods in their version and GWT can not handle it. IMHO convenience
> is the most important thing here.
>
> For example wouldn't it be possible to redefine the way @JsFunction works so
> something like:
>
> 1.) @JsFunction marks a parameter to be a functional parameter
> 2.) The type of the parameter that is marked with @JsFunction must have
> exactly one @JsFunctionTarget in its class definition
> 3.) @JsFunctionTarget marks an abstract method in an interface or in an
> abstract class.
>
>
> Then we would do something like
>
> @JsType(native = true, ...)
> class SomeAsyncClass {
> void onSuccess(@JsFunction Consumer<String> onSuccess);
> }
>
>
> interface Consumer<T> {
> @JsFunctionTarget
> void accept(T value);
>
>
> // other default methods
> }
>
>
>
> JavaScript:
>
> var asyncClass = new SomeAsyncClass();
> var someConsumer = // ...anything that has implemented Consumer<String>
> asyncClass.onSuccess(
> function(value) { // @JsFunction tells GWT to generate a "bridge" method
> using the parameters of @JsFunctionTarget and delegates to the
> Consumer<String> implementation
> someConsumer.accept(value);
> }
> );
>
>
> The above is probably not fully correct JS and maybe has some "this"
> problems but I think you get the idea. Marking parameters as @JsFunction
> would allow you to choose wether or not you want GWT to handle a Consumer as
> callback or as ordinary object, e.g. if you do not annotate a parameter of
> type Consumer with @JsFunction then it will be passed as normal object
> without any bridge methods that delegate to a @JsFunctionTarget method.
>
> Wouldn't this be possible?
>
> -- 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 [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/google-web-toolkit-contributors/db6a7e36-b288-4107-90f2-6b66b696779c%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7eAaSqbKWmMyjne4y%2ByJTmz5pmEHrKbVtBefvhVvXo0gQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
