> 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.
