I think I didn't understand some of your concerns. Let's meet some time this week to flush out what all of this means and the implications.
On Mon, Nov 3, 2014 at 8:45 AM, 'Ray Cromwell' via GWT Contributors < [email protected]> wrote: > Moving from interfaces to classes has other downsides. For example, you > can't avoid not generating a Java class/object, you can't have your own > super-class hierarchy and mark your class as supporting the same interface > as an external JS implemented one, the notion of JS objects "implementing" > a Java interface would seem strange if they implement the interface without > subclassing the prototype of the Java object with the annotation. > > Take something like Elemental 2.0, which is likely to have several > hundred, maybe 1000 types for every conceivable WebUI, we do not want > defineClass(), class literals, castmaps, or java.lang.Object stuff set up > for any of them. With interfaces, it's clear there's no backing interface > to compile. With classes, we'd have to add some hackery to the compiler > like "if it's a jstype, and it has zero implemented methods, and it's all > native, and it doesn't extend another class that has non-native methods, > *then* we can just drop it's class setup from the output". > > Otherwise, for every single one of these you'll get massive bloat, and a > SDM compile of Elemental 2.0 would have a thousand stubbed out classes in > it. > > > On Sat Nov 01 2014 at 10:07:21 AM 'Goktug Gokdogan' via GWT Contributors < > [email protected]> wrote: > >> (I will read & respond to comments after the weekend) >> >> On Sat, Nov 1, 2014 at 9:52 AM, Goktug Gokdogan <[email protected]> >> wrote: >> >>> 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 >>>> [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%3DyUA30t6RmeVs%3D9XGOp4HU0_u_NYu4J42SYJ9HQnH9PgoXSg%40mail.gmail.com >> <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAN%3DyUA30t6RmeVs%3D9XGOp4HU0_u_NYu4J42SYJ9HQnH9PgoXSg%40mail.gmail.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/CAPVRV7eyW-Xw8SHefBOHff6ttUgh5X20ghSn0A9t9V_vcv0aHw%40mail.gmail.com > <https://groups.google.com/d/msgid/google-web-toolkit-contributors/CAPVRV7eyW-Xw8SHefBOHff6ttUgh5X20ghSn0A9t9V_vcv0aHw%40mail.gmail.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%3DyUA1fnYBFYTirydq6KAr6vJojGkg%2BSovs1p9HT%3DhawOcrJg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
