@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] 
> <javascript:>> 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 [email protected] 
>> <javascript:>.
>> 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/d5294e88-77c5-4b6c-a8c0-3337af0b9b02%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to