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