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 [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/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/CAN%3DyUA3bV6-tFK7GHm-3UcphNGOU69R8sJsJNo%3D3t_CVRxpsZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to