Hello, I totally agree on your first two points. I would add a third which is that since this SAM functionnality will be very essential to javascript interoperability, it will be used a lot (already in some projects i am eagerly waiting for this to be implemented, instead of writing my own wrappers). And since it will be used a lot, it needs to be non-invasive (as much as it can).
Your solution is really clean, regarding that point. More, it is expressive, so the developper knows what happens. And since it uses the already defined jsconvert mechanism, it is much simpler. So i would definitely vote for that to happen ! Thanks Arnaud Le Wed Nov 19 2014 at 11:54:29, < [email protected]> a écrit : > [email protected] > <https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!forum/google-web-toolkit-contributors/topics> > Google > Groups > <https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!overview> > <https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!overview> > Topic digest > View all topics > <https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!forum/google-web-toolkit-contributors/topics> > > - Changing the handling of javascript functions and SAMs in JsInterop > <#msg-f:1485197246995020450_group_thread_0> - 1 Update > > Changing the handling of javascript functions and SAMs in JsInterop > <http://groups.google.com/group/google-web-toolkit-contributors/t/7aaf9c2822b04063?utm_source=digest&utm_medium=email> > Goktug Gokdogan <[email protected]>: Nov 18 02:45PM -0800 > > We originally started with the idea that when we encounter a non-JsType > that is a Single-Abstract-Method class (SAM), we will automatically threat > it as a javascript function for interoperability purposes. > For that to work well, we need to make it work in a predictable way. Which > means; > > 1. Behavior shouldn't be broken with runtime type information. > i.e. if the method accepts interface 'Consumer' it should accept any > implementation of Consumer, not some of them (e.g. object that implements > both Consumer and Runnable). > > 2. Referential equality should be preserved at least per SAM definition. > i.e. element.addEventListener(e) and element.removeEventListener(e) > should result in same function given that both methods uses the same SAM > interface. > > I don't think we can diverge from these two in our final solution. However, > this forces us to generate bridge methods that is more complex to > implement, results in extra code bloat and also it can be surprising (e.g. > an object that happens to be a SAM but meant to be an opaque object). > > Anyway, after long discussions we converged into an alternative. > > We are planning to introduce javascript functions to our type system and > explicitly mark them by @JsFunction that has its own restrictions similar > to JsTypes. We will forbid concrete classes to implement/extend multiple > @JsFunction types. With this, they can handled efficiently and will be more > explicit and will behave predictable. > > This option basically prevents simple consumption of java functional > interfaces that appear on JsTypes but we can later handle this (if > necessary) via @JsConvert. This will make 'function <=> SAM' conversion > more explicit. As an additional benefit, it will follow the same code path > as the rest of the @JsConvert while generating the bridge methods. E.g. > > @JsConvert(SamToFunctionConverter.class) > public @Interface ToJsFunction {} > > void forEach(@ToJsFunction Consumer c); > > > I'll update the doc soon. Let us know what you think. > > Cheers. > Back to top <#msg-f:1485197246995020450_digest_top> > You received this digest because you're subscribed to updates for this > group. You can change your settings on the group membership page > <https://groups.google.com/forum/?utm_source=digest&utm_medium=email/#!forum/google-web-toolkit-contributors/join> > . > To unsubscribe from this group and stop receiving emails from it send an > email to [email protected]. > -- 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/CANjaDne62O2%2BbYn32rgRruRKj5jek852dEkpBakAN0ScXD_CsQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
