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 <
google-web-toolkit-contributors@googlegroups.com> 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 <
> google-web-toolkit-contributors@googlegroups.com> wrote:
>
>> (I will read & respond to comments after the weekend)
>>
>> On Sat, Nov 1, 2014 at 9:52 AM, Goktug Gokdogan <gok...@google.com>
>> 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 <
>>> stephen.haber...@gmail.com> 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+unsubscr...@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+unsubscr...@googlegroups.com.
>> 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
> 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
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.
