I think last time I checked everybody was convinced this is the way to go and we are planning towards this. I'll update the spec when I have the chance.
On Thu, Apr 2, 2015 at 6:08 AM, Julien Dramaix <[email protected]> wrote: > Hi all, > > Finally, did you made a decision ? > > I like very much the *native methods* approach for its simplicity and a > test library like PowerMock seems to be able to mock native methods. But > Ray seems to have some concerns about using class instead of Interface. So > what was the selected approach ? > > Julien > > > On Wednesday, November 5, 2014 at 10:37:21 PM UTC+1, Cristian Rinaldi > wrote: >> >> @goktug >> Thanks for the answer!! >> >> >> El miércoles, 5 de noviembre de 2014 17:34:51 UTC-3, Goktug Gokdogan >> escribió: >>> >>> It is compiler magic. The compiler understands from PrototypeOfJsType and >>> assumes any methods in the class are native, hence ignores the method body. >>> >>> On Wed, Nov 5, 2014 at 4:08 AM, Cristian Rinaldi <[email protected]> >>> wrote: >>> >>>> @goktug I like this option, it is expressive and concise. >>>> >>>> But I have a question, >>>> The code generated for the prototype, suppose we are extending some >>>> existing JS functionality and want to add some function, the prototype >>>> generated will have native code?, how this prototype generates subyasente >>>> invoking the JS function? >>>> >>>> by example: >>>> >>>> @JsType(prototype = "Document") >>>> public interface Document { >>>> >>>> public HTMLElement createElement(String div); >>>> >>>> public HTMLElement getElementsByTagName(String body); >>>> >>>> @JsProperty >>>> public HTMLBodyElement getBody(); >>>> >>>> public NodeList querySelector(String selector); >>>> >>>> public NodeList querySelectorAll(String selector); >>>> >>>> class prototype extends Prototype_Document {} >>>> >>>> .... >>>> .... >>>> } >>>> >>>> @PrototypeOfJsType(Document.class) >>>> public class Prototype_Document{ >>>> .... >>>> .... >>>> public NodeList querySelectorAll(String selector){ >>>> //The question (How will called underlying code?) >>>> } >>>> } >>>> >>>> public class MyDocument extends Document.prototype{ >>>> >>>> public void myMethod(){ >>>> //TODO >>>> } >>>> >>>> } >>>> >>>> Cheers :) >>>> >>>> >>>> >>>> >>>> El sábado, 1 de noviembre de 2014 13:52:46 UTC-3, Goktug Gokdogan >>>> escribió: >>>>> >>>>> There is also a third option. >>>>> >>>>> User writes: >>>>> >>>>> @JsType(prototype = "Object")interface JsObject { >>>>> >>>>> class prototype extends Prototype_JsObject {} >>>>> >>>>> interface Static { >>>>> String[] keys(JsObject obj); >>>>> JsObject defineProperties(JsObject obj, JsObject props); >>>>> } >>>>> >>>>> static Static getStatic() { >>>>> return new Static_JsObject(); >>>>> } >>>>> >>>>> static JsObject of(Object obj) { >>>>> return obj instanceof JsObject ? (JsObject) obj : null; >>>>> } >>>>> >>>>> @JsConstructor >>>>> void constructor(String param); >>>>> >>>>> boolean hasOwnProperty(String prop); >>>>> boolean isPrototypeOf(JsObject prop); >>>>> } >>>>> >>>>> >>>>> which generates: >>>>> >>>>> @PrototypeOfJsType(JsObject.class)public class Prototype_JsObject { >>>>> JsObject constructor(String param) { return null;} >>>>> boolean hasOwnProperty(String prop) { return false; } >>>>> boolean isPrototypeOf(JsObject prop) { return false; } >>>>> } >>>>> public class Static_JsObject implements Static { >>>>> JsObject newInstance(String param) { >>>>> return js("new Object($0)", param); >>>>> } >>>>> >>>>> public String[] keys(JsObject obj) { >>>>> return js("Object.keys($0)", obj); >>>>> }; >>>>> >>>>> public JsObject defineProperties(JsObject obj, JsObject props) { >>>>> ... >>>>> } >>>>> } >>>>> >>>>> >>>>> And usage looks like: >>>>> >>>>> MyObject extends JsObject.prototype {} >>>>> >>>>> JsObject.getStatic().keys( ... ); >>>>> >>>>> JsObject.getStatic().newInstance( ... ); >>>>> >>>>> JsObject.of(new Object()); >>>>> >>>>> >>>>> And it is perfectly testable. >>>>> >>>>> On Sat, Nov 1, 2014 at 8:25 AM, Stephen Haberman < >>>>> [email protected]> wrote: >>>>> >>>>>> >>>>>> > I will try to summarize my thought process and different options >>>>>> that >>>>>> > I have played with so that you could get a better understanding >>>>>> where >>>>>> > I'm coming from and I hope it will provide good documentation for >>>>>> > future. >>>>>> >>>>>> Thanks for the email; I think the format was really useful. >>>>>> >>>>>> > One may argue that if we are committing to use some kind of DSL why >>>>>> > not use something else like IDL or xml etc. There are 3 main reasons >>>>>> > to use java + APT instead of others: >>>>>> >>>>>> I really want to advocate APT, as I've used it and do generally like >>>>>> it, >>>>>> but frankly it can be a huge PITA for Eclipse. See long-standing >>>>>> issues >>>>>> e.g.: >>>>>> >>>>>> https://github.com/square/dagger/issues/126 >>>>>> >>>>>> Granted, maybe someone can just fix Eclipse, but, in my experience, it >>>>>> can really ruin the first impressions for a project (1000s of compile >>>>>> errors due to missing generated code, and no hints that, btw, it's >>>>>> because the APT was not on the classpath/didn't run). >>>>>> >>>>>> > All the cons are around the testability aspect. For JRE testing, >>>>>> > native methods are a headache. Also we no longer generate an >>>>>> interface >>>>>> > for static methods. >>>>>> >>>>>> I know I just bitched about APT, but, just musing, what if the class >>>>>> (with the native methods/etc.) was the DSL the user wrote, and then >>>>>> APT >>>>>> just generated an interface from that? >>>>>> >>>>>> This is basically what I'm doing by hand in tessell with writing >>>>>> IsTextBox for TextBox, etc. >>>>>> >>>>>> I admittedly am not an expert on JS prototype semantics, so am not >>>>>> sure >>>>>> how this would handle statics/etc. But in testing I usually only care >>>>>> about instance methods anyway... >>>>>> >>>>>> A few years ago I spiked an APT processor to do this automatically: >>>>>> >>>>>> https://github.com/stephenh/interfacegen >>>>>> >>>>>> The oddity then becomes that the user is writing "class JsObject", but >>>>>> then if they want testable code, they need to code against the >>>>>> generated >>>>>> "IsJsObject" interface. But perhaps that it's optional is a good >>>>>> thing, >>>>>> e.g. you could come back and add the "@GenInterface"-type method later >>>>>> if/when you wanted. >>>>>> >>>>>> Anyway, I think I do like the last proposal, the class/native method >>>>>> best. >>>>>> >>>>>> Thanks, Goktug! >>>>>> >>>>>> - Stephen >>>>>> >>>>>> -- >>>>>> 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 google-web-toolkit-contributors+unsubscribe@ >>>>>> googlegroups.com. >>>>>> To view this discussion on the web visit https://groups.google.com/d/ >>>>>> msgid/google-web-toolkit-contributors/20141101102535.45715a48%40sh9. >>>>>> 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 google-web-toolkit-contributors+unsubscribe@ >>>> googlegroups.com. >>>> To view this discussion on the web visit https://groups.google.com/d/ >>>> msgid/google-web-toolkit-contributors/a10b0e54-eea9- >>>> 4886-bfc0-1103eede4be2%40googlegroups.com >>>> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/a10b0e54-eea9-4886-bfc0-1103eede4be2%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>>> 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/2ccff98a-eb73-40b3-8535-ef456eec5ac7%40googlegroups.com > <https://groups.google.com/d/msgid/google-web-toolkit-contributors/2ccff98a-eb73-40b3-8535-ef456eec5ac7%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > 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/CAN%3DyUA0OHa_4WbcwkhHWWN5CyvVr9j6h%2B-DxKYKiODgNLJk3kg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
