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). > > GWT already requires kind of special setup in Eclipse so I think we are in better shape. Also we will need APT's regardless of this feature as that will be the only way for code generation in the long 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 [email protected]. > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA0qKf24J6SGHO8vA%2B6EiCw3FZyygeRJjqYrw9RhC%3DdN8w%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
