Re: [gwt-contrib] JavaWriter API as replacement for SourceWriter family
Take a look at this comment of Kevin Bourillion about we they dislike Lombok. I couldn't have said It better: http://www.reddit.com/r/java/comments/1y9e6t/ama_were_the_google_team_behind_guava_dagger/cfjf5v5 - Andrés Testi -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] JavaWriter API as replacement for SourceWriter family
BTW, it is unlikely we will adopt lombok. Nice to hear it. Hopefully, the way this works in your IDE is that the moment you create the JsInterface and hit Save, APT will run and create the magic _prototype class, and then you can start writing your Web Component or JS-subtype in Java by extending it without red squigglies. +1 Lombok by contrast required seperate Java IDE plugins for IntelliJ and Eclipse to make this happen. This is another reason why I don't like Lombok. It's not legal Java, tools will not work without special support. - Andrés Testi -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] JavaWriter API as replacement for SourceWriter family
Please, don't adopt Lombok. While it is an interesting project, it is still a hack. We should wait for java8 compiler plugins, because they are an official feature and have a lot more probabilities than lombok to be forward compatible and standardized. Ironically, Reinier Zwitserloot, one of the authors of Lombok, disagreed with me when I proposed Annotation Proccessors as replacement for generators, 7 years ago: https://groups.google.com/d/msg/google-web-toolkit-contributors/2uBiRzMJLgM/v0tX_DXEv6oJ My original intention with this post, was to deprecate a redundant feature like SourceWriter. While the suggested way to go would be APT (I'm not really convinced about it), GWT.create() will stay here for years. I can't see incompatibility between adoption of APT and deprecation of SourceWriter. Promoting the use of tools like JavaWriter instead of GWT-only features, is a good sign for developers to go for other options. Less code to mantain is better. A quick example: Generator.escape() doesn't escapes UTF-8 control characters. To fix it, I must write a patch, pray for its approbation, and wait for the next GWT release. Or I can just use JavaWriter.stringLiteral() . - Andrés Testi El jueves, 27 de febrero de 2014 22:02:14 UTC-3, Ray Cromwell escribió: I think if we move to APT, you can do AST based code-gen via something like a JavaWriter to a stream, or if we adopt lombok, then you construct code by directly manipulating the trees of JavaC and JDT. On Thu Feb 27 2014 at 4:17:15 PM, James Nelson ja...@wetheinter.netjavascript: wrote: Is there anywhere to get a sneak preview on the discussions about the future of codegen? Andres and I have both invested time in some extensions of ast-based codegen, and could really use some time and forewarning to adapt our strategy to stay future-friendly with out apis. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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.comjavascript: . For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: JavaWriter API as replacement for SourceWriter family
Thanks Thomas! I appreciate your response. I thought that JSNI could be implemented with beginControl(public native void foo()/*-); , but JavaWriter checks for open scopes. However I think that JavaWriter is still a valid option for non JSNI code, and the API will evolve to support more use cases. - Andrés Testi El viernes, 28 de febrero de 2014 11:07:59 UTC-3, Thomas Broyer escribió: JavaWriter has many small limitations, and in the case of GWT, the main one is that it's impossible to make it emit JSNI methods (other limitations include: annotations on method arguments, and generic/parameterized methods). It's a really great lib, but I believe it'll never support JSNI (I doubt Jesse/Jake would accept adding support for it; on the other hand, JSNI as we know it is about to disappear if I understood Goktug properly) On Thursday, February 27, 2014 4:06:46 PM UTC+1, Andrés Testi wrote: Hi contribs: Are you aware of Square's JavaWriter API? ( https://github.com/square/javawriter). It comes from the Dagger/Guice/Guava team, and is widely used for code generation (Dagger, AutoFactory and AutoValue What do you think about introduce this dependency as replacement for SourceWriter family in order to reduce GWT core and increase compatibility with external tools? - Andrés Testi -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: JavaWriter API as replacement for SourceWriter family
Nice! - Andrés Testi El viernes, 28 de febrero de 2014 15:11:35 UTC-3, Thomas Broyer escribió: On Friday, February 28, 2014 5:35:41 PM UTC+1, Andrés Testi wrote: However I think that JavaWriter is still a valid option for non JSNI code, and the API will evolve to support more use cases. Sure, and the proposed JavaWriter 3.0 APIhttps://github.com/square/javawriter/issues/50#issuecomment-36330364could possibly allow subclassing to provide a JsniMethod. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] JavaWriter API as replacement for SourceWriter family
Deprecating SourceWriter and replacing it with JavaWriter means encouraging our users (and our own code-base) to move out of SourceWriter to JavaWriter. If we decide APT is the way to go then if someone is going to write generator, it should be APT - in that case internally we may use JavaWriter and externally they could use whatever they want (including the JavaWriter). However, If the generator is already written, then it is a meaningless effort to move out of SourceWriter. All of these together there is very little value compared to the cost of such move (including the annoyance caused by it). Deprecation doesn't implies removal. It could stay deprecated forever, discouraging people to use it for new developments. We don't have yet evidence that APT is able to cover all the Generator use cases. Anyway, as Thomas said, we should priorize modularization. - Andrés Testi -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] JavaWriter API as replacement for SourceWriter family
Hi contribs: Are you aware of Square's JavaWriter API? (https://github.com/square/javawriter). It comes from the Dagger/Guice/Guava team, and is widely used for code generation (Dagger, AutoFactory and AutoValue What do you think about introduce this dependency as replacement for SourceWriter family in order to reduce GWT core and increase compatibility with external tools? - Andrés Testi -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Cannot build any project since 5a972863
I have the same problem. - Andrés Testi El miércoles, 22 de enero de 2014 09:07:08 UTC-3, Honza Rameš escribió: Hello everyone, I'm using master for my projects and after I updated to commit 5a972863 (Added monolithic/separate branching to JavaToJavaScriptCompiler) suddenly I wasn't able to compile any of my GWT projects (in Eclipse, see error message bellow). I'm using jdk_1.7 and older commit (8ef35362) works just fine. Did any of you encountered build breakage recently, is there some workaround you know of? DevMode works OK with this commit. I have Eclipse 3.7 and GPE 3.5.1. While compiling simple project I noticed that some of the permutations compile just fine. Could this be caused by IE6 permutation, I do have some deferred binding rules in my module targeting the IE6. Error messge: [ERROR] Compile failed java.lang.NullPointerException at com.google.gwt.dev.jjs.UnifiedAst.compilePermutation(UnifiedAst.java:137) at com.google.gwt.dev.CompilePerms.compile(CompilePerms.java:196) at com.google.gwt.dev.CompilePermsServer.compilePermutation(CompilePermsServer.java:307) at com.google.gwt.dev.CompilePermsServer.run(CompilePermsServer.java:274) at com.google.gwt.dev.CompilePermsServer.main(CompilePermsServer.java:237) [ERROR] Error from external worker java.lang.NullPointerException at com.google.gwt.dev.jjs.UnifiedAst.compilePermutation(UnifiedAst.java:137) at com.google.gwt.dev.CompilePerms.compile(CompilePerms.java:196) at com.google.gwt.dev.CompilePermsServer.compilePermutation(CompilePermsServer.java:307) at com.google.gwt.dev.CompilePermsServer.run(CompilePermsServer.java:274) at com.google.gwt.dev.CompilePermsServer.main(CompilePermsServer.java:237) [ERROR] Unrecoverable exception, shutting down com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries) at com.google.gwt.dev.ExternalPermutationWorkerFactory$ExternalPermutationWorker.compile(ExternalPermutationWorkerFactory.java:156) at com.google.gwt.dev.PermutationWorkerFactory$Manager$WorkerThread.run(PermutationWorkerFactory.java:73) at java.lang.Thread.run(Thread.java:744) Any help would be appreciated. Regards Honza Rames -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Cannot build any project since 5a972863
Hi John: I'm running ant without explicit target (build by default). No explicit flags. I got the same exception in two isolated environments (ubuntu 13.10 with OpenJDK, and Windows 8 with Oracle JDK). The exception is throwed when the script tries to compile the DynaTable sample. CompilerContext.getModule() seems to return null here: https://github.com/gwtproject/gwt/blob/master/dev/core/src/com/google/gwt/dev/jjs/UnifiedAst.java#L137 - Andrés Testi El miércoles, 22 de enero de 2014 15:45:35 UTC-3, John Stalcup escribió: Yeah that does look to be related to my commit. Which compiler entry point are you launching and with what flags? I updated Compiler.java, CompilePerms.java, etc etc to property setup the module property of the compilerContext object, but it looks like I missed somewhere. John On Wed, Jan 22, 2014 at 4:07 AM, Honza Rameš ram...@gmail.comjavascript: wrote: Hello everyone, I'm using master for my projects and after I updated to commit 5a972863 (Added monolithic/separate branching to JavaToJavaScriptCompiler) suddenly I wasn't able to compile any of my GWT projects (in Eclipse, see error message bellow). I'm using jdk_1.7 and older commit (8ef35362) works just fine. Did any of you encountered build breakage recently, is there some workaround you know of? DevMode works OK with this commit. I have Eclipse 3.7 and GPE 3.5.1. While compiling simple project I noticed that some of the permutations compile just fine. Could this be caused by IE6 permutation, I do have some deferred binding rules in my module targeting the IE6. Error messge: [ERROR] Compile failed java.lang.NullPointerException at com.google.gwt.dev.jjs.UnifiedAst.compilePermutation(UnifiedAst.java:137) at com.google.gwt.dev.CompilePerms.compile(CompilePerms.java:196) at com.google.gwt.dev.CompilePermsServer.compilePermutation(CompilePermsServer.java:307) at com.google.gwt.dev.CompilePermsServer.run(CompilePermsServer.java:274) at com.google.gwt.dev.CompilePermsServer.main(CompilePermsServer.java:237) [ERROR] Error from external worker java.lang.NullPointerException at com.google.gwt.dev.jjs.UnifiedAst.compilePermutation(UnifiedAst.java:137) at com.google.gwt.dev.CompilePerms.compile(CompilePerms.java:196) at com.google.gwt.dev.CompilePermsServer.compilePermutation(CompilePermsServer.java:307) at com.google.gwt.dev.CompilePermsServer.run(CompilePermsServer.java:274) at com.google.gwt.dev.CompilePermsServer.main(CompilePermsServer.java:237) [ERROR] Unrecoverable exception, shutting down com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries) at com.google.gwt.dev.ExternalPermutationWorkerFactory$ExternalPermutationWorker.compile(ExternalPermutationWorkerFactory.java:156) at com.google.gwt.dev.PermutationWorkerFactory$Manager$WorkerThread.run(PermutationWorkerFactory.java:73) at java.lang.Thread.run(Thread.java:744) Any help would be appreciated. Regards Honza Rames -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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.comjavascript: . For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Cannot build any project since 5a972863
Thanks! - Andrés Testi El miércoles, 22 de enero de 2014 16:39:45 UTC-3, John Stalcup escribió: Yeah. It seems that CompilePermsServer doesn't have a ModuleDef instance, so it's not populating compilerContext.getModule(), which laters causes compilerContext.getModule().isMonolithic() to fail. I'm working on a fix. On Wed, Jan 22, 2014 at 11:26 AM, Andrés Testi andres@gmail.comjavascript: wrote: Hi John: I'm running ant without explicit target (build by default). No explicit flags. I got the same exception in two isolated environments (ubuntu 13.10 with OpenJDK, and Windows 8 with Oracle JDK). The exception is throwed when the script tries to compile the DynaTable sample. CompilerContext.getModule() seems to return null here: https://github.com/gwtproject/gwt/blob/master/dev/core/src/com/google/gwt/dev/jjs/UnifiedAst.java#L137 - Andrés Testi El miércoles, 22 de enero de 2014 15:45:35 UTC-3, John Stalcup escribió: Yeah that does look to be related to my commit. Which compiler entry point are you launching and with what flags? I updated Compiler.java, CompilePerms.java, etc etc to property setup the module property of the compilerContext object, but it looks like I missed somewhere. John On Wed, Jan 22, 2014 at 4:07 AM, Honza Rameš ram...@gmail.com wrote: Hello everyone, I'm using master for my projects and after I updated to commit 5a972863 (Added monolithic/separate branching to JavaToJavaScriptCompiler) suddenly I wasn't able to compile any of my GWT projects (in Eclipse, see error message bellow). I'm using jdk_1.7 and older commit (8ef35362) works just fine. Did any of you encountered build breakage recently, is there some workaround you know of? DevMode works OK with this commit. I have Eclipse 3.7 and GPE 3.5.1. While compiling simple project I noticed that some of the permutations compile just fine. Could this be caused by IE6 permutation, I do have some deferred binding rules in my module targeting the IE6. Error messge: [ERROR] Compile failed java.lang.NullPointerException at com.google.gwt.dev.jjs.UnifiedAst.compilePermutation( UnifiedAst.java:137) at com.google.gwt.dev.CompilePerms.compile( CompilePerms.java:196) at com.google.gwt.dev.CompilePermsServer. compilePermutation(CompilePermsServer.java:307) at com.google.gwt.dev.CompilePermsServer.run( CompilePermsServer.java:274) at com.google.gwt.dev.CompilePermsServer.main( CompilePermsServer.java:237) [ERROR] Error from external worker java.lang.NullPointerException at com.google.gwt.dev.jjs.UnifiedAst.compilePermutation( UnifiedAst.java:137) at com.google.gwt.dev.CompilePerms.compile(CompilePerms.java:196) at com.google.gwt.dev.CompilePermsServer.compilePermutation( CompilePermsServer.java:307) at com.google.gwt.dev.CompilePermsServer.run( CompilePermsServer.java:274) at com.google.gwt.dev.CompilePermsServer.main( CompilePermsServer.java:237) [ERROR] Unrecoverable exception, shutting down com.google.gwt.core.ext.UnableToCompleteException: (see previous log entries) at com.google.gwt.dev.ExternalPermutationWorkerFacto ry$ExternalPermutationWorker.compile(ExternalPermutationWorkerFacto ry.java:156) at com.google.gwt.dev.PermutationWorkerFactory$ Manager$WorkerThread.run(PermutationWorkerFactory.java:73) at java.lang.Thread.run(Thread.java:744) Any help would be appreciated. Regards Honza Rames -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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.comjavascript: . For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] GWT,jsni() implemented as rebinding method
BTW, my implementation of GWT.jsni() with rebinding methods was just to show the power of the proposal, not to support the inclusion of the method. El martes, 17 de diciembre de 2013 09:28:25 UTC-3, Andrés Testi escribió: Honestly, I think JSNI should be fully removed from GWT, even GWT.jsni(). JsInterop seems to cover all the JS binding cases, I can't see where JSNI is still useful. JSNI is a dirty hack, it doesn't supports refactoring nor typesafe and it's not really Java. In the other hand, a thing like GWT.debugger() is ugly. It could be useful in JS development, but it doesn't differs so much from Window.alert(Hi bro, I'm debugging the line 123). We already have a debugger, who needs a debugger statement? GWT.* methods are usually intrusive and source of code coupling. That said, I see the need of method rebinding only at JavaToSimplerJava level. JavaToJavaScript should be orthogonal, and fully covered by JsInterop. Of course, I'm really interested in enhance code generation. :-) - Andrés Testi El lunes, 16 de diciembre de 2013 17:51:15 UTC-3, Goktug Gokdogan escribió: On Mon, Dec 16, 2013 at 12:14 PM, Andrés Testi andres@gmail.comwrote: Well, there is a sample for String.format() in the prototype: https://github.com/andrestesti/gwt-rebindingmethods/blob/master/samples/hellorebinding/src/com/google/gwt/sample/hellorebinding/client/util/Strings.java#L39 I agree, method rebinding should eliminate the need of magic methods and simplify the compiler. GWT.debugger() is a controvesial case because Java doesn't has a semantically equivalent for it.. Yes, that is also true for the GWT.jsni case. I think at the end there should be 2 types of rewriters; one for java and one for javascript and they should do real method replacement. Developer can choose either one. It looks like you are really interested in this. Can you also improve your proposal with real method rewriting? - Andrés Testi El lunes, 16 de diciembre de 2013 16:48:52 UTC-3, Goktug Gokdogan escribió: I actually implemented with simple eval for demonstration purposes but probably yours is preferable :) Yes, GWT.jsni is one of the use cases for method rebinding; that was something I was discussing as part of the original discussion. In reality GWT.jsni is better to be implementable without native method definitions so we could eventually take native methods out of the compiler. There are also other use cases like String.format, GWT.debugger and GWT.create itself. The ideal solution should cover all to avoid redundant features in the SDK. On Mon, Dec 16, 2013 at 10:00 AM, Andrés Testi andres@gmail.comwrote: This morning I read the Goktug's slides and was surprised by the GWT.jsni() method. It is a nice use case for rebinding methods. I just added a version of GWT.jsni() to HelloRebinding sample, implementing it as a rebinding method (no compiler mods). It took me just 30 minutes of coding to add an extension to support this: JsniUtil.jsni($wnd.alert(#), message); - Usage: https://github.com/andrestesti/gwt- rebindingmethods/blob/master/samples/hellorebinding/src/ com/google/gwt/sample/hellorebinding/client/MainWidget.java#L65 - Definition: https://github.com/andrestesti/gwt- rebindingmethods/blob/master/samples/hellorebinding/src/ com/google/gwt/sample/hellorebinding/client/util/JsniUtil.java#L38 - Generator: https://github.com/andrestesti/gwt- rebindingmethods/blob/master/samples/hellorebinding/src/ com/google/gwt/sample/hellorebinding/rebind/ JsniSnippetGenerator.java#L32 Regards. - Andrés Testi -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 . For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] GWT,jsni() implemented as rebinding method
This morning I read the Goktug's slides and was surprised by the GWT.jsni() method. It is a nice use case for rebinding methods. I just added a version of GWT.jsni() to HelloRebinding sample, implementing it as a rebinding method (no compiler mods). It took me just 30 minutes of coding to add an extension to support this: JsniUtil.jsni($wnd.alert(#), message); - Usage: https://github.com/andrestesti/gwt-rebindingmethods/blob/master/samples/hellorebinding/src/com/google/gwt/sample/hellorebinding/client/MainWidget.java#L65 - Definition:https://github.com/andrestesti/gwt-rebindingmethods/blob/master/samples/hellorebinding/src/com/google/gwt/sample/hellorebinding/client/util/JsniUtil.java#L38 - Generator: https://github.com/andrestesti/gwt-rebindingmethods/blob/master/samples/hellorebinding/src/com/google/gwt/sample/hellorebinding/rebind/JsniSnippetGenerator.java#L32 Regards. - Andrés Testi -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Rebinding Methods improvement proposal and working prototype
Hi Brian: This is well-documented and looks like solid work. Thanks for the kudos! I think the main issue will be whether it can be made compatible with modular compilation. So the best timing will be to land it after modular compilation. It looks like it should be compatible because the compiler doesn't need to see how a @Rebind method is implemented in order to call the generator for a call site? So we can run the generator in each module that calls a @Rebind-marked interface method. I was very careful when merged John changes. In fact, these where the only merge conflicts I remember during the prototype development. UnifiyAst, JProgram and GwtAstBuilder where our mainly conflicted classes, but he only added constant renamings and support for a new kind of visitor in these files. I think it should not be an issue, since my changes are only AST transformations. I must to elaborate the Implementation Details section to clear doubts. Thanks for read and annotate the proposal! - Andrés Testi -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Rebinding Methods improvement proposal and working prototype
Stephen: Per Brian's comments, a javax.rebinding spec might have a hard time having feature-parity with GWT, because I imagine the Java8 plugins, like APT, only runs on .java files currently under compile, and doesn't re-process all of the types in .class files via .jars on the classpath. I think so. As I know, Java 8 plugins are applied at the AST transformation level. Which, AFAIK, is what John is getting to work--that a .jar (or .gwtlib) is basically compiled, but can have one more global rebinding pass that modifies its contents before GWT writes everything to disk. Nice! I would like to know more details about what John is doing. Well, you mentioned jribble, so now I'm a fan of basically anything you say. :-) I'm aware of your involvement on Scala-GWT, and regret that the project is stopped. Let me know if I can help you and the others to reanimate it! - Andrés Testi -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Rebinding Methods improvement proposal and working prototype
El viernes, 29 de noviembre de 2013 00:51:25 UTC-3, Stephen Haberman escribió: implemented as a Java 8 compiler plugin (extension point) Interesting! I had not heard of these before: It's curious, I googled about Java 8 compiler plugins when RayC said that you talked about a new code-gen feature in Java 8 It looks like these compiler plugins use com.sun packages, and are not a JSR, which AFAIK means no Eclipse IDE nor ecj support? What does that mean for your GWT-free deferred binding proposal? Yes, compiler plugins are an experimental feature, just like annotation processing tool was in Java 5. I hope it will be formalized in future Java versions. My plan is, as a first step, to externalize the Rebind annotation and the Rebinding.create() method/class (a GWT-free replacement for GWT.create()). These could be in an external package, like rebinding (javax.rebinding would be an ideal :-P). Think about this API as a kind of JSR330, a minimalistic API describing only what should be done, but nothing about how to do it. Java 8 would implement it as a compiler plugin, GWT as a compiler improvement (we already have it, just look at my github profile :-P). In a second step, we could externalize the generator API, may be in a rebinding.generator package (again, an ideal would be javax.rebinding.generator). GWT-free generators should use javax.lang.model.type.*http://docs.oracle.com/javase/7/docs/api/javax/lang/model/type/package-summary.html instead of com.google.gwt.core.ext.typeinfo.*http://www.gwtproject.org/javadoc/latest/com/google/gwt/core/ext/typeinfo/package-summary.html . In Java 8, these could be implemented as compiler plugins. In GWT, these new generators would be a kind of wrappers for old generators. In a third step, we could externalize the deferred binding configuration (i.e. *.gwt.xml files). Annotations and/or guice like modules are interesting options. That aside, I think a GWT-free deferred binding API would be pretty sexy. If one were starting GWT from scratch, I'd naively assert/agree that the problems of build-time codegen and transpiling .java to .js are orthogonal, and so should be tackled separately. Which would ideally make both implementations smaller/simpler/better. Yes, in and ideal world, I would like to have these compilation steps: JavaCode = JavaToJRibbleCompiler (Java 8 compiler plugin) = JRibbleCode JRibbleCode = JRibbleToJavaScriptCompiler = JavaScriptCode As we live in a dirty corrupted world, we must replicate implementations. For JRE/Android, we could implement it as Java 8 plugin/JDT extension (if it exists)/whatever. In GWT, as a compiler enhancement (It already exists!). Anyway, it's really exciting to see your contributions, Andres, your write up was very good. You are welcome, thanks for your feedback! - Andrés Testi -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Rebinding Methods improvement proposal and working prototype
Note that we are currently very closer to the first step of the externalization plan. We must only refactor 2 classes. - Andrés Testi El viernes, 29 de noviembre de 2013 09:49:31 UTC-3, Andrés Testi escribió: El viernes, 29 de noviembre de 2013 00:51:25 UTC-3, Stephen Haberman escribió: implemented as a Java 8 compiler plugin (extension point) Interesting! I had not heard of these before: It's curious, I googled about Java 8 compiler plugins when RayC said that you talked about a new code-gen feature in Java 8 It looks like these compiler plugins use com.sun packages, and are not a JSR, which AFAIK means no Eclipse IDE nor ecj support? What does that mean for your GWT-free deferred binding proposal? Yes, compiler plugins are an experimental feature, just like annotation processing tool was in Java 5. I hope it will be formalized in future Java versions. My plan is, as a first step, to externalize the Rebind annotation and the Rebinding.create() method/class (a GWT-free replacement for GWT.create()). These could be in an external package, like rebinding (javax.rebinding would be an ideal :-P). Think about this API as a kind of JSR330, a minimalistic API describing only what should be done, but nothing about how to do it. Java 8 would implement it as a compiler plugin, GWT as a compiler improvement (we already have it, just look at my github profile :-P). In a second step, we could externalize the generator API, may be in a rebinding.generator package (again, an ideal would be javax.rebinding.generator). GWT-free generators should use javax.lang.model.type.*http://docs.oracle.com/javase/7/docs/api/javax/lang/model/type/package-summary.html instead of com.google.gwt.core.ext.typeinfo.*http://www.gwtproject.org/javadoc/latest/com/google/gwt/core/ext/typeinfo/package-summary.html . In Java 8, these could be implemented as compiler plugins. In GWT, these new generators would be a kind of wrappers for old generators. In a third step, we could externalize the deferred binding configuration (i.e. *.gwt.xml files). Annotations and/or guice like modules are interesting options. That aside, I think a GWT-free deferred binding API would be pretty sexy. If one were starting GWT from scratch, I'd naively assert/agree that the problems of build-time codegen and transpiling .java to .js are orthogonal, and so should be tackled separately. Which would ideally make both implementations smaller/simpler/better. Yes, in and ideal world, I would like to have these compilation steps: JavaCode = JavaToJRibbleCompiler (Java 8 compiler plugin) = JRibbleCode JRibbleCode = JRibbleToJavaScriptCompiler = JavaScriptCode As we live in a dirty corrupted world, we must replicate implementations. For JRE/Android, we could implement it as Java 8 plugin/JDT extension (if it exists)/whatever. In GWT, as a compiler enhancement (It already exists!). Anyway, it's really exciting to see your contributions, Andres, your write up was very good. You are welcome, thanks for your feedback! - Andrés Testi -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Rebinding Methods improvement proposal and working prototype
The last 3 months I have been working on a GWT Improvement Proposal
inspired by the idea of Ray Cromwell for Relaxing constraints on
GWT.create()http://timepedia.blogspot.com.ar/2009/03/relaxing-constraints-on-gwtcreate.html.
I wrote a technical document and implemented it as a fork
of GWT master at GitHubhttps://github.com/andrestesti/gwt-rebindingmethods
.
As a quick example of what is possible to do with Rebinding Methods, you
can look at the hellorebinding
samplehttps://github.com/andrestesti/gwt-rebindingmethods/blob/master/samples/hellorebinding/src/com/google/gwt/sample/hellorebinding/client/MainWidget.java#L39
:
public MainWidget() {
/*
* No boilerplate required to bind user interfaces.
*/
initWidget(UiBinders.createAndBindUi(Widget.class, MainWidget.class, this));
}
The working prototype is fully functional, and passed the same test suites
than GWT master. DevMode works fine, and I think SuperDevMode should work
too.
Please, feel free to add feedback in the document and/or GitHub. I
apologize for my possible grammatical errors, since I'm not english native
speaker.
Links of interest:
- Ray Cromwell's blog post:
http://timepedia.blogspot.com.ar/2009/03/relaxing-constraints-on-gwtcreate.html
- Rebinding Methods proposal:
https://docs.google.com/document/d/1K25f6-Hxtlj31pthapfUhmNxS1OPiUXZFtHDnHGjrpg
- Working prototype: https://github.com/andrestesti/gwt-rebindingmethods
Thanks in advance.
- Andrés Testi
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
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.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Rebinding Methods improvement proposal and working prototype
Thanks, Juan Pablo. You are welcome :-)
El jueves, 28 de noviembre de 2013 11:21:39 UTC-3, juan_pablo_gardella
escribió:
Thanks Andrés! Great work
2013/11/28 Andrés Testi andres@gmail.com javascript:
The last 3 months I have been working on a GWT Improvement Proposal
inspired by the idea of Ray Cromwell for Relaxing constraints on
GWT.create()http://timepedia.blogspot.com.ar/2009/03/relaxing-constraints-on-gwtcreate.html.
I wrote a technical document and implemented it as a fork
of GWT master at GitHubhttps://github.com/andrestesti/gwt-rebindingmethods
.
As a quick example of what is possible to do with Rebinding Methods, you
can look at the hellorebinding
samplehttps://github.com/andrestesti/gwt-rebindingmethods/blob/master/samples/hellorebinding/src/com/google/gwt/sample/hellorebinding/client/MainWidget.java#L39
:
public MainWidget() {
/*
* No boilerplate required to bind user interfaces.
*/
initWidget(UiBinders.createAndBindUi(Widget.class, MainWidget.class,
this));
}
The working prototype is fully functional, and passed the same test
suites than GWT master. DevMode works fine, and I think SuperDevMode should
work too.
Please, feel free to add feedback in the document and/or GitHub. I
apologize for my possible grammatical errors, since I'm not english native
speaker.
Links of interest:
- Ray Cromwell's blog post:
http://timepedia.blogspot.com.ar/2009/03/relaxing-constraints-on-gwtcreate.html
- Rebinding Methods proposal:
https://docs.google.com/document/d/1K25f6-Hxtlj31pthapfUhmNxS1OPiUXZFtHDnHGjrpg
- Working prototype: https://github.com/andrestesti/gwt-rebindingmethods
Thanks in advance.
- Andrés Testi
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
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.comjavascript:
.
For more options, visit https://groups.google.com/groups/opt_out.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
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.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Rebinding Methods improvement proposal and working prototype
Hi Goktug: The problem is, as I noted in earlier discussions, the semantics of this feature is pretty complex. It is difficult to understand what is going on and how to properly use it. Also in addition to that it adds more responsibility to the compiler and forces a more opinionated style of extension. The semantics of this feature may be complex only for API developers, but not for API client developers. It is not more complex than a GWT.create() invocation. An invocation to something like String.format(hello %s, name), should be transparent for a common developer. On the other hand, as we discussed earlier, we want to compiler to do the less and give more options at the library level. The new feature you are proposing, the GWT.create feature itself and many others can be reasonably handled by a single extension point that provides basic method re-writing. If you read the Future Work section of my proposal, you will find that I'm proposing a GWT-free API, implemented as a Java 8 compiler plugin (extension point). As today GWT compiler is not pluggable, we must modify the compiler to explore these options. Thanks for your feedback! - Andrés Testi -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Rebinding Methods improvement proposal and working prototype
The problem is, as I noted in earlier discussions, the semantics of this feature is pretty complex. It is difficult to understand what is going on and how to properly use it. BTW, take a look at the Java semantics preservationhttps://docs.google.com/document/d/1K25f6-Hxtlj31pthapfUhmNxS1OPiUXZFtHDnHGjrpg/edit?hl=esforcehl=1#bookmark=id.588al1rpv8u9 section. Regards. - Andrés Testi -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Thoughts on GWT 3.0 re: Java 8 and IE 8/9
Are other source languages than Java taken into account for GWT 3.0? Is Jribble considered? - Andrés Testi El viernes, 25 de octubre de 2013 13:18:52 UTC-3, Thomas Broyer escribió: Forwarded from the GWT group, so it's not lost in the middle of support questions. Link to the topic (there's some feedback there as well): https://groups.google.com/d/topic/google-web-toolkit/Ll0W3Ui1CAI/discussion On Friday, October 25, 2013 4:50:38 PM UTC+2, Andy wrote: I just read through the notes from the GWT steering committeehttps://groups.google.com/d/msg/gwt-steering/ldyo7OXUnHQ/ogtT-kPFoaoJand would like to share our perspective. I know you have a lot of survey results and we're just 1 company, but here's some more info based on our needs. *Java 8 only* I would encourage and support this move. I've been writing a ton of Javascript for the past few weeks and really miss the functional style when I come back to Java. Lambdas in Java 8 are going to be powerful and fun and they should be used liberally throughout the GWT 3.0 APIs. We won't be able to move our backend to Java 8 for a while, but since we only ship the JS output of the GWT compiler, I'm happy to use Java 8 for front-end development. *Dropping IE 8/9* * * We just decided on Tuesday to drop IE7 with our next release. We got tired of working around hasLayout bugs, etc. We have several major customers that still have users with XP/IE7, but after consulting with them, we decided we could go ahead with dropping support. Unfortunately, many of our customers are using IE8 and we won't be able to drop IE 8/9 anytime soon. As a developer this is extremely frustrating, but it's the sad reality of the enterprise. So Java 8 would be awesome, but dropping support for IE 8/9 would prevent us from being about to use GWT 3.0 until our enterprise customers upgrade their browsers. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] What is the porpouse of ReboundTypeRecorder?
I just found this class in the master but I can't find references to it. Where is ReboundTypeRecorder intended to be used? Thanks. - Andrés Testi -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] What is the porpouse of ReboundTypeRecorder?
Thanks for the clarification, John. Does this mean that UnifyAst.UnifyVisitor.handleGwtCreate() will be deprecated/removed? I'm afraid because I'm working on a prototype with heavy changes on handleGwtCreate(). - Andrés Testi El viernes, 25 de octubre de 2013 16:17:55 UTC-3, John Stalcup escribió: it's purpose is described in https://gwt-review.googlesource.com/#/c/4981/ On Fri, Oct 25, 2013 at 12:13 PM, Andrés Testi andres@gmail.comjavascript: wrote: I just found this class in the master but I can't find references to it. Where is ReboundTypeRecorder intended to be used? Thanks. - Andrés Testi -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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.comjavascript: . For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] What is the porpouse of ReboundTypeRecorder?
What I'm doing is a prototype for GWT.create() enhancement originally proposed by Ray Cronwell, and discussed in this group a few months ago. My prototype is near to be ready (next weekend I hope). I'm trying to keep it in sync with master, but if I detect that master has changes I can't handle, I will stop the merges. My intention is to have a working prototype to discuss possible improvements. My proposal is only syntactic sugar on GWT.create(), mainly source transformation. I don't think separated compilation will be an issue. Thanks. - Andrés Testi El viernes, 25 de octubre de 2013 16:54:06 UTC-3, John Stalcup escribió: since we're both making changes to the rebinding system, there's a very good chance that our changes are going to collide. i'm in the process of breaking my separate compilation prototype into small pieces (generally 200-500 lines), cleaning them up, testing them, getting them reviewed, and then committed. i've got about 5500 lines remaining to run through this process. it sounds like you have a lot of outstanding changes as well. maybe yours and my changes will merge best if you do the same thing (iteratively commit in lots of small chunks). On Fri, Oct 25, 2013 at 12:41 PM, John Stalcup sta...@google.comjavascript: wrote: Mmmm, yes and no. as you know GWT.create() rebinding right now in our monolithic build pass is statically calculated at compile time. i'm working on adding a separate build pass and this pass requires that GWT.create() handling be done dynamically at runtime. the monolithic pass has smaller output and longer compile time and is best for production releases. the separate pass has larger output and shorter compile time and is best for developer productivity. so monolithic compilation and it's compile time GWT.create() rebinding will never completely go away since it is key to smallest possible output size. that being said, any extension of GWT.create() functionality that can't also be implemented at runtime for the separate compilation pass, will not be approved, at least not by me. On Fri, Oct 25, 2013 at 12:25 PM, Andrés Testi andres@gmail.comjavascript: wrote: Thanks for the clarification, John. Does this mean that UnifyAst.UnifyVisitor.handleGwtCreate() will be deprecated/removed? I'm afraid because I'm working on a prototype with heavy changes on handleGwtCreate(). - Andrés Testi El viernes, 25 de octubre de 2013 16:17:55 UTC-3, John Stalcup escribió: it's purpose is described in https://gwt-review.** googlesource.com/#/c/4981/https://gwt-review.googlesource.com/#/c/4981/ On Fri, Oct 25, 2013 at 12:13 PM, Andrés Testi andres@gmail.comwrote: I just found this class in the master but I can't find references to it. Where is ReboundTypeRecorder intended to be used? Thanks. - Andrés Testi -- http://groups.google.com/**group/Google-Web-Toolkit-**Contributorshttp://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/**groups/opt_outhttps://groups.google.com/groups/opt_out . -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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.comjavascript: . For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Where is gwt-customchecks.jar?
Thanks Colin! I'm glad to see the power of the community in action :-) - Andrés Testi El lunes, 21 de octubre de 2013 19:59:53 UTC-3, Colin Alworth escribió: Tentative patch up at https://gwt-review.googlesource.com/5063 - can someone sanity check it for me? It looks like step 4 (now step 3) should have previously been pointing to step 3 (now step 2), so is now more correct. On Sunday, October 20, 2013 2:12:17 PM UTC-5, Andrés Testi wrote: Thanks Thomas. I think it should be removed from eclipse/README.txt. - Andrés Testi El domingo, 20 de octubre de 2013 13:25:24 UTC-3, Thomas Broyer escribió: On Friday, October 18, 2013 5:30:25 PM UTC+2, Andrés Testi wrote: Where is the gwt-customchecks.jar file referred in eclipse/README.txt? Is it no longer required to configure codecheck? Thanks in advance. It's gone, and no longer required. See https://gwt-review.googlesource.com/1051 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Where is gwt-customchecks.jar?
The changes may be small and easy, but consequences may be great. In this case, your change will save lots of useless google searches to newbie contributors ;-) - Andrés Testi El martes, 22 de octubre de 2013 10:32:43 UTC-3, Colin Alworth escribió: If only *all* of my changes were that easy to make... On Tuesday, October 22, 2013 8:15:12 AM UTC-5, Andrés Testi wrote: Thanks Colin! I'm glad to see the power of the community in action :-) - Andrés Testi El lunes, 21 de octubre de 2013 19:59:53 UTC-3, Colin Alworth escribió: Tentative patch up at https://gwt-review.googlesource.com/5063 - can someone sanity check it for me? It looks like step 4 (now step 3) should have previously been pointing to step 3 (now step 2), so is now more correct. On Sunday, October 20, 2013 2:12:17 PM UTC-5, Andrés Testi wrote: Thanks Thomas. I think it should be removed from eclipse/README.txt. - Andrés Testi El domingo, 20 de octubre de 2013 13:25:24 UTC-3, Thomas Broyer escribió: On Friday, October 18, 2013 5:30:25 PM UTC+2, Andrés Testi wrote: Where is the gwt-customchecks.jar file referred in eclipse/README.txt? Is it no longer required to configure codecheck? Thanks in advance. It's gone, and no longer required. See https://gwt-review.googlesource.com/1051 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Where is gwt-customchecks.jar?
Thanks Thomas. I think it should be removed from eclipse/README.txt. - Andrés Testi El domingo, 20 de octubre de 2013 13:25:24 UTC-3, Thomas Broyer escribió: On Friday, October 18, 2013 5:30:25 PM UTC+2, Andrés Testi wrote: Where is the gwt-customchecks.jar file referred in eclipse/README.txt? Is it no longer required to configure codecheck? Thanks in advance. It's gone, and no longer required. See https://gwt-review.googlesource.com/1051 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Where is gwt-customchecks.jar?
Where is the gwt-customchecks.jar file referred in eclipse/README.txt? Is it no longer required to configure codecheck? Thanks in advance. - Andrés Testi -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Where is gwt-customchecks.jar?
Thanks Michael! I will search it. - Andrés Testi El viernes, 18 de octubre de 2013 12:51:40 UTC-3, Michael Vogt escribió: Hello. I found it in the old svn repository. Sorry can't provide the link right now, but you'll find it with your preferred search engine ;-) Hope this helps, Michael -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: Initial support for @GwtCreate (code-gen methods)
Hi James, thanks for your feedback!
Note that the @GwtCreate class parameters aren't replaced by
GwtCreateFactory as was originally suggested by Ray Cromwell. This provides
access to actual parameters.
It would be possible to do a full replacement if the factory also gave
access to the class field, and any code in the method block accessing the
class could be re-routed through the factory.
Though, I see no good reason why to do the extra work this way, I figured
I'd mention it in case someone else has a use case for it.
I think that having the class field isolated from GwtCreateFactory, the
code pruner would have better opportunities to remove the extra parameter.
* Upcoming improvements:
1) Support for explicit generators
@GwtCreate(generator = FooGenerator.class)
Did you see my pull request with some (very) basic support for this?
https://gwt-review.googlesource.com/#/c/4000/
Sure! I studied your patch before implementing this one.
2) Multiple parameters for GWT.create() by means of @GwtCreate.Param
U, O UiBinderU, O createBinder(
@GwtCreate(generator = UiBinGen.class) final ClassU uiType,
@GwtCreate.Param final ClassO ownerType) {
Is the intention here to just send more classes to the generator,
or to actually send parameters to the constructor of the rebound object
being instantiated?
The intention here is to send more than one arguments to the generator by
means a special annotation as was suggested by Ray.
Foo createFoo(
@GwtCreate final Class? extends Foo fooType,
@GwtCreate.Param final Class? arg1,
@GwtCreate.Param final Class? arg2) {
return GWT.create(fooType, arg1, arg2);
}
Sending classes is no good, because the constructor needs the values.
Personally, I think the best solution is to add the parameters to
@GwtCreate;
Foo createFoo(
@GwtCreate({String.class, int.class})
final Class? extends Foo fooType,
String arg1, int arg2) {
return GWT.create(fooType, arg1, arg2);
}
Class values in annotations must be class literals, so that makes that
easy.
My intention was to provide extra parameters as arguments for code-gen
methods, i.e:
createUiBinder(Widget.class, Owner.class, template.ui.xml);
It also means we don't care about the order of extra parameters sent to
the method,
nor are we forced to get these values from the method parameters (or even
declare GWT.create params as params in method);
the invocation of GWT.create(cls, params) would simply supply the
JExpressions to pass along to constructors.
(Have to pull out the initializers from the JNewArray made by the
generics, but that's simple).
I assume we would be changing GWT.create to be create(Class? c, Object
... params);
the compiler could bail if params.length 0 anywhere that's not in a
method (method w/ parameter) annotated with @GwtCreate.
Then, add a JType[] and JExpression[] to JGwtCreate to be able to find the
right constructor and have values to send it
(not sure if unboxing would work without a tweak, but that's no biggie).
The only hard-ish part would be updating ResolveRebinds to pass along the
list of JExpressions correctly.
Do you have any work started in this area, cos I'd be glad to give it a
shot / send over a pull request.
No, I don't have did nothing in this are, you are welcome to join efforts
and ideas :-)
To allow mixed multiple code-gen parameters, we would bind main
parameters by name
F extends Foo, B extends Bar
void mixedMultiple(
@GwtCreate final ClassF fooType,
@GwtCreate.Param(fooType) final Class? fooArg,
@GwtCreate final ClassB barType,
@GwtCreate.Param(barType) final Class? barArg)
I really don't like this much typing to wire stuff up.
Putting the params in the @GwtCreate would make this much cleaner:
F extends Foo, B extends Bar B create(
@GwtCreate({String.class}) final ClassF fooType,
@GwtCreate({Foo.class}) final ClassB barType) {
F foo = GWT.create(fooType, some string);
return GWT.create(barType, foo); // params can come from anywhere
}
As I mentioned before, I want to pass some string as argument to
create(fooType, barType, String)
3) Support for GWT.create(this.getClass()) ? not exactly, but...
Explicits generators can eliminate the issue of the unique generator
per class hierarchy. An aditional boolean parameter for @GwtCreate would
mitigate the code size issue
abstract class UiBinderComposite extends UiBinderComposite {
public UiBinderComposite() {
UiBinderWidget, UiBinderComposite binder =
createBinder(getClass());
}
private static UiBinderWidget, UiBinderComposite
createBinder(@GwtCreate(
// The explicit
Re: [gwt-contrib] Initial support for @GwtCreate (code-gen methods)
Hi Brian, thanks for the feedback!
What you proposes is not so hard to add, but I want the API end users to
not have to deal with GWT.create() at all.
El lunes, 19 de agosto de 2013 19:18:24 UTC-3, Brian Slesinsky escribió:
Interesting. I like the idea of replacing class parameters with something
else. I'm not sure we need to sweep the implementation under the rug.
Particularly in fancier scenarios, it might be easier to work with it
explicitly.
Suppose we have:
/** Encapsulates a GWT create call. */
interface CreatorT {
Class? getClassLiteral();
ListObject getArgs();
T get();
}
public class GWT {
...
/** Performs a GWT.create() call an encapsulates the result. */
final T CreatorT creator(Class? classLiteral, Object... args);
}
Then you can write code that takes a Creator:
MyService s = createService(GWT.creator(MyService.class), arg);
static S extends FooService S createService(CreatorS creator, String
arg) {
S s = creator.get();
// do some initialization involving arg.
return s;
}
This is how you write it without any compiler magic. But we would also
support using a bare class:
MyService s = createService(MyService.class, arg);
static S extends FooService S createService(@Creator final ClassS
theClass, String arg) {
S s = GWT.create(theClass);
// do some initialization involving arg.
return s;
}
The compiler rewrites any Class arg marked as @Creator to actually take a
Creator, inserts the GWT.creator() call at the call site, and replaces the
GWT.create() call with a creator.get() call in the API. So we have compiler
magic to make the API look pretty for simple cases, but it's not strictly
necessary since you could write the same thing yourself (at the cost of
some verbosity).
(I bundled the arguments along with the class since that seemed like the
most conservative approach. I'm not sure what happens if you have
compile-time arguments coming from the different places than the class
itself.)
All the compile-time arguments are required to come from the same place,
being all literal or all @GwtCreate arguments.
Foo createFoo(@GwtCreate Class? extends Foo type, @GwtCreate.Param
String str) {
// This will compile
GWT.create(type, str);
// This will fail
GWT.create(type, hello);
// This will compile
GWT.create(Foo.class, hello);
}
- Andrés
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
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.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Possible GWT.create() Improvements (link)
As an alternative to what Goktug proposed about macros, we would have an
equivalent to Scala macros (sorry for insisting with Scala :-) )
@Macro(SumGenerator.class)
Integer sum(Integer arg0, Integer arg1) {
// We will never be here
return null;
}
// rebind space
class SumGenerator {
ExprInteger sum(GeneratorContext ctx, TreeLogger logger, ArgInteger
arg0, ArgInteger arg1) {
if(arg0.isLiteral() arg1.isLiteral()) {
// If both arguments are literals, we sum they at compile time
Integer result = arg0.getValue() + arg1.getValue();
return ctx.compile(return {};, result);
}
// We return a runtime sum
return ctx.compile(return {} + {};, arg0, arg1);
}
}
- Andrés
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
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.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Initial support for @GwtCreate (code-gen methods)
Thank Ray :-)
The patch has as an issue with constructor code-gen that I solved, but GIT
doesn't allows me to push merges.
Of course, has you a link to explore the javac compiler-plugin alternative?
Thanks!
- Andrés
El sábado, 17 de agosto de 2013 01:28:53 UTC-3, Ray Cromwell escribió:
Andres, this looks amazing! I've been out this week on vacation but
returning tomorrow, I'll take a look when I return.
On Fri, Aug 16, 2013 at 2:22 AM, Andrés Testi
andres@gmail.comjavascript:
wrote:
I've been working on a prototype inspired by Ray Cromwell's proposal for
@GwtCreate parameters, borrowing some ideas from Scala implicit macros. I
apologize for not to post this in the Possible GWT.create() Improvements
thread, but this message is too long to be only a comment.
You can check my patch at https://gwt-review.googlesource.com/4110. This
prototype has passed many JUnit tests cases and works fine (only fails
JEnumTypeTest after my last pull, I don't know why). Devmode also works.
This proposal differs from Ray's original idea in that @GwtCreate is a
parameter annotation instead of a method annotation. Later I will justify
this decision.
This new proposal consists on rewriting methods adding a trailing
implicit parameter of type GwtCreateFactory for each parameter annotated
with @GwtCreate. GwtCreateFactory is a hidden interface used by the
compiler:
interface GwtCreateFactory {
T T create();
}
When the compiler finds a code-gen method like
Foo createFoo(@GwtCreate final Class? extends Foo fooType) {
return GWT.create(fooType);
}
it is rewritten as
Foo createFoo(final Class? extends Foo type, GwtCreateFactory
fooType$factory) {
return fooType$factory.create();
}
IMPORTANT:
The @GwtCreate parameter requires to be final.
This proposal doesn't require constant evaluation expression. The
final modifier is required to disable non reproductible side effects.
At method call site, an invocation like
Foo foo = createFoo(SubFoo.class);
is rewritten as
class SubFoo$GwtCreateFactory implements GwtCreateFactory {
@Override public T T create() {
return GWT.create(SubFoo.class);
}
}
Foo foo = createFoo(SubFoo.class, new SubFoo$GwtCreateFactory());
Just like Scala implicit parameters, @GwtCreate can fight against type
erasure and subtyping
interface FooCreator {
T extends Foo T create(@GwtCreate ClassT fooType);
}
class FooCreatorImpl extends FooCreator {
T extends Foo T create(@GwtCreate final ClassT fooType) {
return GWT.create(fooType);
}
}
code-gen constructors are supported too
class CreateByConstructorT extends Foo {
final T instance;
public CreateByConstructor(@GwtCreate final ClassT fooType) {
instance = GWT.create(fooType);
}
}
Again, as in Scala implicit parameters, nesting is allowed
class Foo {}
class SubFoo extends Foo {}
F extends Foo F createFoo(@GwtCreate final ClassF fooType) {
return GWT.create(fooType);
}
S extends SubFoo S createSubFoo(@GwtCreate final ClassS subFooType)
{
return createFoo(subFooType);
}
The decision to locate @GwtCreate on parameters was taken to support
mixed code-gen methods
F extends Foo, B extends Bar
void fooBarCreator(@GwtCreate final ClassF fooType, @GwtCreate final
ClassB barType) {
foo = GWT.create(fooType);
bar = GWT.create(barType);
}
Note that the @GwtCreate class parameters aren't replaced by
GwtCreateFactory as was originally suggested by Ray Cromwell. This provides
access to actual parameters.
ClassT storedType;
T instance;
void createFoo(@GwtCreate final ClassT type) {
storedType = type;
instance = GWT.create(type);
}
* Further improvements:
1) Support for explicit generators
@GwtCreate(generator = FooGenerator.class)
We should forbid assignation between parameters that differs in
@GwtCreate signature
Foo createFoo(@GwtCreate(generator = FooGen.class) final Class?
extends Foo) {...}
// This will fail
Foo forbiddenNesting(@GwtCreate(generator = BarGen.class) final
Class? extends Foo fooType) {
return createFoo(fooType);
}
2) Multiple parameters for GWT.create() by means of @GwtCreate.Param
U, O UiBinderU, O createBinder(
@GwtCreate(generator = UiBinGen.class) final ClassU uiType,
@GwtCreate.Param final ClassO ownerType) {
return GWT.create(uiType, ownerType);
}
@GwtCreate.Params must respect the same kind of signature rules than
@GwtCreate, and a strict order of invocation
// Good ordering
Foo createFoo(
@GwtCreate final Class? extends Foo fooType,
@GwtCreate.Param final Class? arg1,
@GwtCreate.Param final Class? arg2) {
return GWT.create(fooType, arg1, arg2
Re: [gwt-contrib] Initial support for @GwtCreate (code-gen methods)
BTW consider that I forgot to commit @GwtCreate annotation, you can find it here: https://gwt-review.googlesource.com/#/c/4111/ Where I wrote Further Improvements, I meant Upcoming Improvements (I'm not native english speaker) - Andrés -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Initial support for @GwtCreate (code-gen methods)
I've been working on a prototype inspired by Ray Cromwell's proposal for
@GwtCreate parameters, borrowing some ideas from Scala implicit macros. I
apologize for not to post this in the Possible GWT.create() Improvements
thread, but this message is too long to be only a comment.
You can check my patch at https://gwt-review.googlesource.com/4110. This
prototype has passed many JUnit tests cases and works fine (only fails
JEnumTypeTest after my last pull, I don't know why). Devmode also works.
This proposal differs from Ray's original idea in that @GwtCreate is a
parameter annotation instead of a method annotation. Later I will justify
this decision.
This new proposal consists on rewriting methods adding a trailing implicit
parameter of type GwtCreateFactory for each parameter annotated with
@GwtCreate. GwtCreateFactory is a hidden interface used by the compiler:
interface GwtCreateFactory {
T T create();
}
When the compiler finds a code-gen method like
Foo createFoo(@GwtCreate final Class? extends Foo fooType) {
return GWT.create(fooType);
}
it is rewritten as
Foo createFoo(final Class? extends Foo type, GwtCreateFactory
fooType$factory) {
return fooType$factory.create();
}
IMPORTANT:
The @GwtCreate parameter requires to be final.
This proposal doesn't require constant evaluation expression. The
final modifier is required to disable non reproductible side effects.
At method call site, an invocation like
Foo foo = createFoo(SubFoo.class);
is rewritten as
class SubFoo$GwtCreateFactory implements GwtCreateFactory {
@Override public T T create() {
return GWT.create(SubFoo.class);
}
}
Foo foo = createFoo(SubFoo.class, new SubFoo$GwtCreateFactory());
Just like Scala implicit parameters, @GwtCreate can fight against type
erasure and subtyping
interface FooCreator {
T extends Foo T create(@GwtCreate ClassT fooType);
}
class FooCreatorImpl extends FooCreator {
T extends Foo T create(@GwtCreate final ClassT fooType) {
return GWT.create(fooType);
}
}
code-gen constructors are supported too
class CreateByConstructorT extends Foo {
final T instance;
public CreateByConstructor(@GwtCreate final ClassT fooType) {
instance = GWT.create(fooType);
}
}
Again, as in Scala implicit parameters, nesting is allowed
class Foo {}
class SubFoo extends Foo {}
F extends Foo F createFoo(@GwtCreate final ClassF fooType) {
return GWT.create(fooType);
}
S extends SubFoo S createSubFoo(@GwtCreate final ClassS subFooType) {
return createFoo(subFooType);
}
The decision to locate @GwtCreate on parameters was taken to support mixed
code-gen methods
F extends Foo, B extends Bar
void fooBarCreator(@GwtCreate final ClassF fooType, @GwtCreate final
ClassB barType) {
foo = GWT.create(fooType);
bar = GWT.create(barType);
}
Note that the @GwtCreate class parameters aren't replaced by
GwtCreateFactory as was originally suggested by Ray Cromwell. This provides
access to actual parameters.
ClassT storedType;
T instance;
void createFoo(@GwtCreate final ClassT type) {
storedType = type;
instance = GWT.create(type);
}
* Further improvements:
1) Support for explicit generators
@GwtCreate(generator = FooGenerator.class)
We should forbid assignation between parameters that differs in
@GwtCreate signature
Foo createFoo(@GwtCreate(generator = FooGen.class) final Class?
extends Foo) {...}
// This will fail
Foo forbiddenNesting(@GwtCreate(generator = BarGen.class) final
Class? extends Foo fooType) {
return createFoo(fooType);
}
2) Multiple parameters for GWT.create() by means of @GwtCreate.Param
U, O UiBinderU, O createBinder(
@GwtCreate(generator = UiBinGen.class) final ClassU uiType,
@GwtCreate.Param final ClassO ownerType) {
return GWT.create(uiType, ownerType);
}
@GwtCreate.Params must respect the same kind of signature rules than
@GwtCreate, and a strict order of invocation
// Good ordering
Foo createFoo(
@GwtCreate final Class? extends Foo fooType,
@GwtCreate.Param final Class? arg1,
@GwtCreate.Param final Class? arg2) {
return GWT.create(fooType, arg1, arg2);
}
// Bad ordering, this will fail
Foo createFoo(
@GwtCreate final Class? extends Foo fooType,
@GwtCreate.Param final Class? arg1,
@GwtCreate.Param final Class? arg2) {
return GWT.create(fooType, arg2, arg1);
}
To allow mixed multiple code-gen parameters, we would bind main
parameters by name
F extends Foo, B extends Bar
void mixedMultiple(
@GwtCreate final ClassF fooType,
@GwtCreate.Param(fooType) final Class? fooArg,
@GwtCreate final ClassB barType,
@GwtCreate.Param(barType) final Class? barArg)
3)
[gwt-contrib] Initial support for @GwtCreate parameters (code-gen methods)
I've been working on a prototype inspired by Ray Cromwell's proposal for
@GwtCreate parameters, borrowing some ideas from Scala implicit macros. I
apologize for not to post this in the Possible GWT.create() Improvements
thread, but this message is too long to be only a comment.
You can check my patch at https://gwt-review.googlesource.com/4110. This
prototype has passed many JUnit tests cases and works fine. Devmode also
works.
This proposal differs from Ray's original idea in that @GwtCreate is a
parameter annotation instead of a method annotation. Later I will justify
this decision.
This new proposal consists on rewriting methods adding a trailing implicit
parameter of type GwtCreateFactory for each parameter annotated with
@GwtCreate. GwtCreateFactory is a hidden interface used by the compiler:
interface GwtCreateFactory {
T T create();
}
When the compiler finds a code-gen method like
Foo createFoo(@GwtCreate final Class? extends Foo fooType) {
return GWT.create(fooType);
}
it is rewritten as
Foo createFoo(final Class? extends Foo type, GwtCreateFactory
fooType$factory) {
return fooType$factory.create();
}
IMPORTANT:
The @GwtCreate parameter requires to be final.
This proposal doesn't require constant evaluation expression. The
final modifier is required to disable non reproductible side effects.
At method call site, an invocation like
Foo foo = createFoo(SubFoo.class);
is rewritten as
class SubFoo$GwtCreateFactory implements GwtCreateFactory {
@Override public T T create() {
return GWT.create(SubFoo.class);
}
}
Foo foo = createFoo(SubFoo.class, new SubFoo$GwtCreateFactory());
Just like Scala implicit parameters, @GwtCreate can fight against type
erasure and subtyping
interface FooCreator {
T extends Foo T create(@GwtCreate ClassT fooType);
}
class FooCreatorImpl extends FooCreator {
T extends Foo T create(@GwtCreate final ClassT fooType) {
return GWT.create(fooType);
}
}
code-gen constructors are supported too
class CreateByConstructorT extends Foo {
final T instance;
public CreateByConstructor(@GwtCreate final ClassT fooType) {
instance = GWT.create(fooType);
}
}
Again, as in Scala implicit parameters, nesting is allowed
class Foo {}
class SubFoo extends Foo {}
F extends Foo F createFoo(@GwtCreate final ClassF fooType) {
return GWT.create(fooType);
}
S extends SubFoo S createSubFoo(@GwtCreate final ClassS subFooType) {
return createFoo(subFooType);
}
The decision to locate @GwtCreate on parameters was taken to support mixed
code-gen methods
F extends Foo, B extends Bar
void fooBarCreator(@GwtCreate final ClassF fooType, @GwtCreate final
ClassB barType) {
foo = GWT.create(fooType);
bar = GWT.create(barType);
}
Note that the @GwtCreate class parameters aren't replaced by
GwtCreateFactory as was originally suggested by Ray Cromwell. This provides
access to actual parameters.
ClassT storedType;
T instance;
void createFoo(@GwtCreate final ClassT type) {
storedType = type;
instance = GWT.create(type);
}
* Further improvements:
1) Support for explicit generators
@GwtCreate(generator = FooGenerator.class)
We should forbid assignation between parameters that differs in
@GwtCreate signature
Foo createFoo(@GwtCreate(generator = FooGen.class) final Class?
extends Foo) {...}
// This will fail
Foo forbiddenNesting(@GwtCreate(generator = BarGen.class) final
Class? extends Foo fooType) {
return createFoo(fooType);
}
2) Multiple parameters for GWT.create() by means of @GwtCreate.Param
U, O UiBinderU, O createBinder(
@GwtCreate(generator = UiBinGen.class) final ClassU uiType,
@GwtCreate.Param final ClassO ownerType) {
return GWT.create(uiType, ownerType);
}
@GwtCreate.Params must respect the same kind of signature rules than
@GwtCreate, and a strict order of invocation
// Good ordering
Foo createFoo(
@GwtCreate final Class? extends Foo fooType,
@GwtCreate.Param final Class? arg1,
@GwtCreate.Param final Class? arg2) {
return GWT.create(fooType, arg1, arg2);
}
// Bad ordering, this will fail
Foo createFoo(
@GwtCreate final Class? extends Foo fooType,
@GwtCreate.Param final Class? arg1,
@GwtCreate.Param final Class? arg2) {
return GWT.create(fooType, arg2, arg1);
}
To allow mixed multiple code-gen parameters, we would bind main
parameters by name
F extends Foo, B extends Bar
void mixedMultiple(
@GwtCreate final ClassF fooType,
@GwtCreate.Param(fooType) final Class? fooArg,
@GwtCreate final ClassB barType,
@GwtCreate.Param(barType) final Class? barArg)
3) Support for GWT.create(this.getClass()) ? not exactly, but...
[gwt-contrib] Initial support for @GwtCreate (code-gen methods)
I've been working on a prototype inspired by Ray Cromwell's proposal for
@GwtCreate parameters, borrowing some ideas from Scala implicit macros. I
apologize for not to post this in the Possible GWT.create() Improvements
thread, but this message is too long to be only a comment.
You can check my patch at https://gwt-review.googlesource.com/4110. This
prototype has passed many JUnit tests cases and works fine (only fails
JEnumTypeTest after my last pull, I don't know why). Devmode also works.
This proposal differs from Ray's original idea in that @GwtCreate is a
parameter annotation instead of a method annotation. Later I will justify
this decision.
This new proposal consists on rewriting methods adding a trailing implicit
parameter of type GwtCreateFactory for each parameter annotated with
@GwtCreate. GwtCreateFactory is a hidden interface used by the compiler:
interface GwtCreateFactory {
T T create();
}
When the compiler finds a code-gen method like
Foo createFoo(@GwtCreate final Class? extends Foo fooType) {
return GWT.create(fooType);
}
it is rewritten as
Foo createFoo(final Class? extends Foo type, GwtCreateFactory
fooType$factory) {
return fooType$factory.create();
}
IMPORTANT:
The @GwtCreate parameter requires to be final.
This proposal doesn't require constant evaluation expression. The
final modifier is required to disable non reproductible side effects.
At method call site, an invocation like
Foo foo = createFoo(SubFoo.class);
is rewritten as
class SubFoo$GwtCreateFactory implements GwtCreateFactory {
@Override public T T create() {
return GWT.create(SubFoo.class);
}
}
Foo foo = createFoo(SubFoo.class, new SubFoo$GwtCreateFactory());
Just like Scala implicit parameters, @GwtCreate can fight against type
erasure and subtyping
interface FooCreator {
T extends Foo T create(@GwtCreate ClassT fooType);
}
class FooCreatorImpl extends FooCreator {
T extends Foo T create(@GwtCreate final ClassT fooType) {
return GWT.create(fooType);
}
}
code-gen constructors are supported too
class CreateByConstructorT extends Foo {
final T instance;
public CreateByConstructor(@GwtCreate final ClassT fooType) {
instance = GWT.create(fooType);
}
}
Again, as in Scala implicit parameters, nesting is allowed
class Foo {}
class SubFoo extends Foo {}
F extends Foo F createFoo(@GwtCreate final ClassF fooType) {
return GWT.create(fooType);
}
S extends SubFoo S createSubFoo(@GwtCreate final ClassS subFooType) {
return createFoo(subFooType);
}
The decision to locate @GwtCreate on parameters was taken to support mixed
code-gen methods
F extends Foo, B extends Bar
void fooBarCreator(@GwtCreate final ClassF fooType, @GwtCreate final
ClassB barType) {
foo = GWT.create(fooType);
bar = GWT.create(barType);
}
Note that the @GwtCreate class parameters aren't replaced by
GwtCreateFactory as was originally suggested by Ray Cromwell. This provides
access to actual parameters.
ClassT storedType;
T instance;
void createFoo(@GwtCreate final ClassT type) {
storedType = type;
instance = GWT.create(type);
}
* Upcoming improvements:
1) Support for explicit generators
@GwtCreate(generator = FooGenerator.class)
We should forbid assignation between parameters that differs in
@GwtCreate signature
Foo createFoo(@GwtCreate(generator = FooGen.class) final Class?
extends Foo) {...}
// This will fail
Foo forbiddenNesting(@GwtCreate(generator = BarGen.class) final
Class? extends Foo fooType) {
return createFoo(fooType);
}
2) Multiple parameters for GWT.create() by means of @GwtCreate.Param
U, O UiBinderU, O createBinder(
@GwtCreate(generator = UiBinGen.class) final ClassU uiType,
@GwtCreate.Param final ClassO ownerType) {
return GWT.create(uiType, ownerType);
}
@GwtCreate.Params must respect the same kind of signature rules than
@GwtCreate, and a strict order of invocation
// Good ordering
Foo createFoo(
@GwtCreate final Class? extends Foo fooType,
@GwtCreate.Param final Class? arg1,
@GwtCreate.Param final Class? arg2) {
return GWT.create(fooType, arg1, arg2);
}
// Bad ordering, this will fail
Foo createFoo(
@GwtCreate final Class? extends Foo fooType,
@GwtCreate.Param final Class? arg1,
@GwtCreate.Param final Class? arg2) {
return GWT.create(fooType, arg2, arg1);
}
To allow mixed multiple code-gen parameters, we would bind main
parameters by name
F extends Foo, B extends Bar
void mixedMultiple(
@GwtCreate final ClassF fooType,
@GwtCreate.Param(fooType) final Class? fooArg,
@GwtCreate final ClassB barType,
@GwtCreate.Param(barType) final Class? barArg)
3)
[gwt-contrib] Re: Initial support for @GwtCreate (code-gen methods)
I forgot to upload the @GwtCreate annotation. You can find It here
https://gwt-review.googlesource.com/#/c/4111/
Regards
- Andrés
El viernes, 16 de agosto de 2013 06:30:15 UTC-3, Andrés Testi escribió:
I've been working on a prototype inspired by Ray Cromwell's proposal for
@GwtCreate parameters, borrowing some ideas from Scala implicit macros. I
apologize for not to post this in the Possible GWT.create() Improvements
thread, but this message is too long to be only a comment.
You can check my patch at https://gwt-review.googlesource.com/4110. This
prototype has passed many JUnit tests cases and works fine (only fails
JEnumTypeTest after my last pull, I don't know why). Devmode also works.
This proposal differs from Ray's original idea in that @GwtCreate is a
parameter annotation instead of a method annotation. Later I will justify
this decision.
This new proposal consists on rewriting methods adding a trailing implicit
parameter of type o for each parameter annotated with @GwtCreate.
GwtCreateFactory is a hidden interface used by the compiler:
interface GwtCreateFactory {
T T create();
}
When the compiler finds a code-gen method like
Foo createFoo(@GwtCreate final Class? extends Foo fooType) {
return GWT.create(fooType);
}
it is rewritten as
Foo createFoo(final Class? extends Foo type, GwtCreateFactory
fooType$factory) {
return fooType$factory.create();
}
IMPORTANT:
The @GwtCreate parameter requires to be final.
This proposal doesn't require constant evaluation expression. The
final modifier is required to disable non reproductible side effects.
At method call site, an invocation like
Foo foo = createFoo(SubFoo.class);
is rewritten as
class SubFoo$GwtCreateFactory implements GwtCreateFactory {
@Override public T T create() {
return GWT.create(SubFoo.class);
}
}
Foo foo = createFoo(SubFoo.class, new SubFoo$GwtCreateFactory());
Just like Scala implicit parameters, @GwtCreate can fight against type
erasure and subtyping
interface FooCreator {
T extends Foo T create(@GwtCreate ClassT fooType);
}
class FooCreatorImpl extends FooCreator {
T extends Foo T create(@GwtCreate final ClassT fooType) {
return GWT.create(fooType);
}
}
code-gen constructors are supported too
class CreateByConstructorT extends Foo {
final T instance;
public CreateByConstructor(@GwtCreate final ClassT fooType) {
instance = GWT.create(fooType);
}
}
Again, as in Scala implicit parameters, nesting is allowed
class Foo {}
class SubFoo extends Foo {}
F extends Foo F createFoo(@GwtCreate final ClassF fooType) {
return GWT.create(fooType);
}
S extends SubFoo S createSubFoo(@GwtCreate final ClassS subFooType) {
return createFoo(subFooType);
}
The decision to locate @GwtCreate on parameters was taken to support mixed
code-gen methods
F extends Foo, B extends Bar
void fooBarCreator(@GwtCreate final ClassF fooType, @GwtCreate final
ClassB barType) {
foo = GWT.create(fooType);
bar = GWT.create(barType);
}
Note that the @GwtCreate class parameters aren't replaced by
GwtCreateFactory as was originally suggested by Ray Cromwell. This provides
access to actual parameters.
ClassT storedType;
T instance;
void createFoo(@GwtCreate final ClassT type) {
storedType = type;
instance = GWT.create(type);
}
* Upcoming improvements:
1) Support for explicit generators
@GwtCreate(generator = FooGenerator.class)
We should forbid assignation between parameters that differs in
@GwtCreate signature
Foo createFoo(@GwtCreate(generator = FooGen.class) final Class?
extends Foo) {...}
// This will fail
Foo forbiddenNesting(@GwtCreate(generator = BarGen.class) final
Class? extends Foo fooType) {
return createFoo(fooType);
}
2) Multiple parameters for GWT.create() by means of @GwtCreate.Param
U, O UiBinderU, O createBinder(
@GwtCreate(generator = UiBinGen.class) final ClassU uiType,
@GwtCreate.Param final ClassO ownerType) {
return GWT.create(uiType, ownerType);
}
@GwtCreate.Params must respect the same kind of signature rules than
@GwtCreate, and a strict order of invocation
// Good ordering
Foo createFoo(
@GwtCreate final Class? extends Foo fooType,
@GwtCreate.Param final Class? arg1,
@GwtCreate.Param final Class? arg2) {
return GWT.create(fooType, arg1, arg2);
}
// Bad ordering, this will fail
Foo createFoo(
@GwtCreate final Class? extends Foo fooType,
@GwtCreate.Param final Class? arg1,
@GwtCreate.Param final Class? arg2) {
return GWT.create(fooType, arg2, arg1);
}
To allow mixed multiple code-gen parameters
[gwt-contrib] Re: Initial support for @GwtCreate (code-gen methods)
JEnumTypeTest doesn't fails anymore, I think the issue was solved yesterday :-) -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Possible GWT.create() Improvements (link)
This reminds me a lot of Scala macros research. As you probably know, Scala solves code-gen issues with experimental support for several kinds of macros, distinguishing clearly between expression-level and type-level code generation/rewriting. APT covers only a fraction of type-level generation, while GWT.create() covers type-level and a little of expression-level rewriting. In standard JRE applications, expression-level is solved with runtime reflection, but in GWT, we must rely on GWT.create(). We always need expression-level handles to get access to the instances of the generated classes. Take a look at Dagger, injections are generated with APT (type-level) and expression-level handles are done with ObjectGraph by means of runtime reflection: // APT can't save us here, we need runtime reflection ObjectGraph objectGraph = ObjectGraph.create(new DripCoffeeModule()); APT and GWT.create() are complementary done the lack of runtime reflection support in GWT. In this sense, I think the Ray's proposal is a step forward. We can't get rid off GWT.create(), but we can hide it as possible from end users. Only API authors should treat with GWT.create(). El viernes, 9 de agosto de 2013 20:16:55 UTC-3, Goktug Gokdogan escribió: I think in the long-run we should separate the two concepts that is being tackled by GWT.create today. First purpose is the class replacement, especially used by permutations. I think this one should not have anything to do with GWT.create. We can do any class replacement in compiler without requiring a call to GWT.create. This is similar to super-sourcing and can be solved similar and perhaps together. Second purpose is for triggering generators and what most of the proposal are about. As Roberto and perhaps others have been bringing up, it is best to follow regular java code generation practices in GWT. That means for the long-term we can mostly rely on AnnotationProcessors. There are many advantages of that: 1. Not GWT only - continue sharing code with server (JRE), client(GWT) and mobile(Android). 2. IDE support: IDE can trigger codegen (esp. for debugging) 3. Parallelizing the compilation and ease moving from JDT into java 8 compiler plugin. 4. Reusing knowledge from java world and lower the barrier for entry to generators. With that move, deferred binding definition for code generator can be just about providing the naming conventions such as class_name - class_name$Generated. Based on the rule, when the compiler sees GWT.create(A.class), it can be turned into new A$Generated() and expect the generated code to be there. The reason I'm bringing this up is; for any proposal I think it is best to keep it feasible w.r.t this aspect and not push us into a corner for the long run. On Fri, Aug 9, 2013 at 1:24 PM, Brian Slesinsky skyb...@google.comjavascript: wrote: Hi, I've published a document [1] with my thoughts on some of the GWT.create() proposals. This doesn't cover everything we've discussed but I think it's a start. If you're on this mailing list you should be able to comment. - Brian [1] https://docs.google.com/document/d/1MDqiBEMl7dylYliAceLBBxGFAlSvkQB9b-kSlnKmZBk/edit?disco=AGXMcRI# -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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.comjavascript: . For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Possible GWT.create() Improvements (link)
I miss this line in my dagger example: CoffeeApp coffeeApp = objectGraph.get(CoffeeApp.class); El sábado, 10 de agosto de 2013 16:23:50 UTC-3, Andrés Testi escribió: This reminds me a lot of Scala macros research. As you probably know, Scala solves code-gen issues with experimental support for several kinds of macros, distinguishing clearly between expression-level and type-level code generation/rewriting. APT covers only a fraction of type-level generation, while GWT.create() covers type-level and a little of expression-level rewriting. In standard JRE applications, expression-level is solved with runtime reflection, but in GWT, we must rely on GWT.create(). We always need expression-level handles to get access to the instances of the generated classes. Take a look at Dagger, injections are generated with APT (type-level) and expression-level handles are done with ObjectGraph by means of runtime reflection: // APT can't save us here, we need runtime reflection ObjectGraph objectGraph = ObjectGraph.create(new DripCoffeeModule()); APT and GWT.create() are complementary done the lack of runtime reflection support in GWT. In this sense, I think the Ray's proposal is a step forward. We can't get rid off GWT.create(), but we can hide it as possible from end users. Only API authors should treat with GWT.create(). El viernes, 9 de agosto de 2013 20:16:55 UTC-3, Goktug Gokdogan escribió: I think in the long-run we should separate the two concepts that is being tackled by GWT.create today. First purpose is the class replacement, especially used by permutations. I think this one should not have anything to do with GWT.create. We can do any class replacement in compiler without requiring a call to GWT.create. This is similar to super-sourcing and can be solved similar and perhaps together. Second purpose is for triggering generators and what most of the proposal are about. As Roberto and perhaps others have been bringing up, it is best to follow regular java code generation practices in GWT. That means for the long-term we can mostly rely on AnnotationProcessors. There are many advantages of that: 1. Not GWT only - continue sharing code with server (JRE), client(GWT) and mobile(Android). 2. IDE support: IDE can trigger codegen (esp. for debugging) 3. Parallelizing the compilation and ease moving from JDT into java 8 compiler plugin. 4. Reusing knowledge from java world and lower the barrier for entry to generators. With that move, deferred binding definition for code generator can be just about providing the naming conventions such as class_name - class_name$Generated. Based on the rule, when the compiler sees GWT.create(A.class), it can be turned into new A$Generated() and expect the generated code to be there. The reason I'm bringing this up is; for any proposal I think it is best to keep it feasible w.r.t this aspect and not push us into a corner for the long run. On Fri, Aug 9, 2013 at 1:24 PM, Brian Slesinsky skyb...@google.comwrote: Hi, I've published a document [1] with my thoughts on some of the GWT.create() proposals. This doesn't cover everything we've discussed but I think it's a start. If you're on this mailing list you should be able to comment. - Brian [1] https://docs.google.com/document/d/1MDqiBEMl7dylYliAceLBBxGFAlSvkQB9b-kSlnKmZBk/edit?disco=AGXMcRI# -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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 . For more options, visit https://groups.google.com/groups/opt_out. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- 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. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Patch to support GWT.create(this.getClass())
Ray:
I'm writing a design doc like Nextgen GWT/JS Interop, but for
Relaxation of GWT.create(). I don't know if there are previous official
efforts to bring something like this to life, but if so, I would like know
about similar experiences.
Is there a guideline for these kind of design doc? When I finish a first
document draft, I will share it.
Thanks!
- Andrés
El miércoles, 7 de agosto de 2013 14:31:01 UTC-3, Ray Cromwell escribió:
The annotations were also there to allow the compiler to do error checking
so that class-literal propagation was always possible. So if you write a
function foo(Class? klazz), that then calls GWT.create(klazz), there will
be a compile time error thrown if foo() is not called with a literal, just
like GWT.create(). This means that it will always be possible to propagate
the class literal from parameter to use.
On Wed, Aug 7, 2013 at 5:31 AM, Andrés Testi
andres@gmail.comjavascript:
wrote:
Hi Ray. I would like to add your proposal to my patch and generalize
GWT.create() relaxation. I think your annotation @GwtCreate(generator=...)
would solve my problem with the GWT frameworks tendency to instantiate
everything with GWT.create() instead of new.
As Matt Mastracci proposed here
https://groups.google.com/d/msg/google-web-toolkit-contributors/_jf8vBC8QDI/X9LDLTbqB64J
a
better approach is to generate a GwtCreateFactory to replace @GwtCreate
Class fields and params.
I will elaborate a more advanced proposal with all of these in account.
Thanks!
- Andrés
El lunes, 5 de agosto de 2013 20:37:45 UTC-3, Ray Cromwell escribió:
Hey Andres, I haven't fully looked at this, but I'm overjoyed you're
working on it, and it seems promising. One thing you might want to do is
review one of my old proposals on allowing any method to delegate
parameters to GWT.create(), see here: http://timepedia.**
blogspot.com/2009/03/relaxing-**constraints-on-gwtcreate.htmlhttp://timepedia.blogspot.com/2009/03/relaxing-constraints-on-gwtcreate.html
I'm wondering if your work could be adapted to support this.
-Ray
On Mon, Aug 5, 2013 at 8:36 AM, Andrés Testi andres@gmail.comwrote:
Are there interest adding support for allowing
GWT.create(this.getClass()) invocations?
I wrote an experimental patch to support it, adding a few changes to
UnifyAst. I've added the patch as an attached file, because I don't have
yet a CLA (I know this is not the right way to proceed).
There are many usecases for this feature, based in the super type token
pattern (http://gafter.blogspot.com.**ar/2006/12/super-type-tokens.**
html http://gafter.blogspot.com.ar/2006/12/super-type-tokens.html).
I've named this feature as Self Generated Objects (selfgen).
* Some use cases are:
-- Hide invocations to GWT.create()
-- Reduce boilerplate, minimizing the need of extend interfaces like
UiBinder, EditorDriver, etc..
Example, a custom composite :
abstract class UiBinderComposite extends Composite {
protected UiBinderComposite() {
UiBinderWidget, UiBinderComposite binder =
GWT.create(this.getClass());
initWidget(binder.**createAndBindUi(this));
}
}
// Usage:
@UiTemplate(mywidget.ui.xml)
class MyUiBinderWidget extends UiBinderComposite {
@UiField
Button clickMe;
}
-- Allow runtime type information on demand (Stroustrup’s zero-overhead
rule: “what you don’t use, you don’t pay for”) by means of emulation of
guava's TypeToken
Example:
abstract class TypeTokenT {
private final TypeInfoT typeInfo;
protected TypeToken() {
typeInfo = GWT.create(this.getClass());
}
...
}
// Usage
new TypeTokenListString(){}
* Implementation
To support this feature, my patch searchs for
GWT.create(this.getClass()) invocations, and replaces they with an
invocation to a syntetic method named this$create. This method is added to
the current class, and is implemented for each non abstract subclass,
returning an invocation to GWT.create(currentClass).
* Problems found with this implementation:
-- Anonymous classes are hidden to generators, and it is unable to do
something like new TypeTokenListString(){}. Workaround: Expose these
classes.
-- GWT frameworks have a tendence to instantiate user objects calling
GWT.create() instead of new operator. With GWT.create(this.getClass()) we
want to instantiate a diferent class, like UiBinder in UiBinderComposite.
Workaroud: Provide a flag to generators reporting if the invocation was
from a class literal or a this.getClass() invocation.
I've added a sample application to my patch, called HelloSelfgen,
demostrating how to write a self generated UiBinderComposite.
Regards.
- Andrés
--
http://groups.google.com/**group/Google-Web-Toolkit-**Contributorshttp://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google
Groups GWT Contributors group
Re: [gwt-contrib] Patch to support GWT.create(this.getClass())
I agree Brian, we first must know what we want.
- Andrés
El viernes, 9 de agosto de 2013 18:41:07 UTC-3, Brian Slesinsky escribió:
I've published that doc here:
https://docs.google.com/document/d/1MDqiBEMl7dylYliAceLBBxGFAlSvkQB9b-kSlnKmZBk/edit?disco=AGXNBZg#heading=h.gks1bp7hz61l
To clarify, I'm not myself working on any GWT.create() enhancements, but I
thought it was worth documenting my concerns in greater detail rather than
just sending a -2. I think it's possible to improve GWT.create() but I want
to make sure we fully understand what we're getting ourselves into.
On Fri, Aug 9, 2013 at 1:57 PM, Ray Cromwell cromw...@google.comjavascript:
wrote:
Andres,
You might want to wait a day or two. I think Brian started one by copy
and pasting your proposals and mine into a doc, it might be better for him
to make it public and we all hack on that.
On Fri, Aug 9, 2013 at 12:19 PM, Andrés Testi
andres@gmail.comjavascript:
wrote:
Ray:
I'm writing a design doc like Nextgen GWT/JS Interop, but for
Relaxation of GWT.create(). I don't know if there are previous official
efforts to bring something like this to life, but if so, I would like know
about similar experiences.
Is there a guideline for these kind of design doc? When I finish a first
document draft, I will share it.
Thanks!
- Andrés
El miércoles, 7 de agosto de 2013 14:31:01 UTC-3, Ray Cromwell escribió:
The annotations were also there to allow the compiler to do error
checking so that class-literal propagation was always possible. So if you
write a function foo(Class? klazz), that then calls GWT.create(klazz),
there will be a compile time error thrown if foo() is not called with a
literal, just like GWT.create(). This means that it will always be
possible
to propagate the class literal from parameter to use.
On Wed, Aug 7, 2013 at 5:31 AM, Andrés Testi andres@gmail.comwrote:
Hi Ray. I would like to add your proposal to my patch and generalize
GWT.create() relaxation. I think your annotation
@GwtCreate(generator=...)
would solve my problem with the GWT frameworks tendency to instantiate
everything with GWT.create() instead of new.
As Matt Mastracci proposed here https://groups.google.com/d/**
msg/google-web-toolkit-**contributors/_jf8vBC8QDI/**X9LDLTbqB64Jhttps://groups.google.com/d/msg/google-web-toolkit-contributors/_jf8vBC8QDI/X9LDLTbqB64J
a
better approach is to generate a GwtCreateFactory to replace @GwtCreate
Class fields and params.
I will elaborate a more advanced proposal with all of these in account.
Thanks!
- Andrés
El lunes, 5 de agosto de 2013 20:37:45 UTC-3, Ray Cromwell escribió:
Hey Andres, I haven't fully looked at this, but I'm overjoyed you're
working on it, and it seems promising. One thing you might want to do is
review one of my old proposals on allowing any method to delegate
parameters to GWT.create(), see here: http://timepedia.**blogspo**
t.com/2009/03/relaxing-**constra**ints-on-gwtcreate.htmlhttp://timepedia.blogspot.com/2009/03/relaxing-constraints-on-gwtcreate.html
I'm wondering if your work could be adapted to support this.
-Ray
On Mon, Aug 5, 2013 at 8:36 AM, Andrés Testi andres@gmail.comwrote:
Are there interest adding support for allowing
GWT.create(this.getClass()) invocations?
I wrote an experimental patch to support it, adding a few changes to
UnifyAst. I've added the patch as an attached file, because I don't
have
yet a CLA (I know this is not the right way to proceed).
There are many usecases for this feature, based in the super type
token pattern (http://gafter.blogspot.com.**ar**
/2006/12/super-type-tokens.**htm**lhttp://gafter.blogspot.com.ar/2006/12/super-type-tokens.html).
I've named this feature as Self Generated Objects (selfgen).
* Some use cases are:
-- Hide invocations to GWT.create()
-- Reduce boilerplate, minimizing the need of extend interfaces like
UiBinder, EditorDriver, etc..
Example, a custom composite :
abstract class UiBinderComposite extends Composite {
protected UiBinderComposite() {
UiBinderWidget, UiBinderComposite binder =
GWT.create(this.getClass());
initWidget(binder.**createAndBin**dUi(this));
}
}
// Usage:
@UiTemplate(mywidget.ui.xml)
class MyUiBinderWidget extends UiBinderComposite {
@UiField
Button clickMe;
}
-- Allow runtime type information on demand (Stroustrup’s
zero-overhead rule: “what you don’t use, you don’t pay for”) by means
of
emulation of guava's TypeToken
Example:
abstract class TypeTokenT {
private final TypeInfoT typeInfo;
protected TypeToken() {
typeInfo = GWT.create(this.getClass());
}
...
}
// Usage
new TypeTokenListString(){}
* Implementation
To support this feature, my patch searchs for
GWT.create(this.getClass()) invocations, and replaces they with an
invocation to a syntetic method named this$create. This method
[gwt-contrib] Does Composite still make sense?
Since IsWidget is a first class interface, what is the use case to use Composite instead of simply implement IsWidget? Thanks in advance. - Andrés -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: RequestFactoryServlet
Since ServiceLayerCache enforces service instances to be singleton, the threadlocal instance will be the same between requests. I reported this issue: http://code.google.com/p/google-web-toolkit/issues/detail?id=6355 - Andrés On 24 mayo, 14:15, Ray Ryan rj...@google.com wrote: The blog post would be great. We'll plunder from it freely for our own samples and docs. One note: lately we've been using Objectify rather than JDO for appengine apps. It's pretty pleasant. On Tue, May 24, 2011 at 7:31 AM, Etienne P. etienne...@gmail.com wrote: I've gone through the same effort to get this working using Google Guice based on some pointers provided by Thomas Broyer in another discussion. It works quite well and could be reused easily across applications. I've even done some integration with the JDO API to get this working in GAE (not without a good amount of trial and error). I'll be posting detailed instructions on my blog and committing some code to github that people can reuse easily. Unless there is a better place for it in which case I'd be glad to contribute the code there as well. Suggestions? On May 23, 10:14 pm, Jeff Larsen larse...@gmail.com wrote: Oh and I did test this to make sure it would with Spring. If you're interested here is a link to my test project. https://github.com/larsenje/SpringRequestFactoryExample -- http://groups.google.com/group/Google-Web-Toolkit-Contributors -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Makes EventBus available outside of the gwt package, in (issue1394803)
You're reading web to mean HTML. I'm reading it as app that talks to a web service, regardless of what it's written in. I really like the GWT event model and want to use it in Guice applications to raise bussiness rules, dispatch entity lifecycle events, etc.. I think this events API is useful for more than web service projects. Regards. - Andrés -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Makes EventBus available outside of the gwt package, in (issue1394803)
Why bindery package is nested in a web package? Are these APIs not available for non web applications? Regards. - Andrés On 31 mar, 01:19, rj...@google.com wrote: Ready for review. John, can you keep me honest on the treatment of com.google.gwt.event.shared, and the choices made in the new event package? Bob, does this fit what you have in mind for the bindery organization? Note that I've updated Activity and Place to use the new classes, but not RequestFactory. I won't submit this until Dan has his big patch in place, and I'll make the RF changes before I do. http://gwt-code-reviews.appspot.com/1394803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: RR: Promoting RequestFactory to a higher package
+1 for this! Are there similar plans for com.google.gwt.i18n? Also com.google.gwt.event could be useful in non GWT projects. Regards. - Andrés On 25 mar, 18:19, Ray Ryan rj...@google.com wrote: RequestFactory is proving itself useful in non-GWT contexts, so we would like to give it more independence. Our plan with the GWT 2.3 release is to copy com.google.gwt.requestfactory to com.google.requestfactory, and deprecate everything in the old location. We will also provide a jar that includes the pure JRE version of request factory with no other GWT dependencies. (This change will probably not make the first 2.3 milestone release.) With 2.4, we'll delete the code in the old location. This is faster than usual promise of keeping deprecated code in place for two releases, but we really don't want to leave so much redundant code around any longer than we have to. The API will not change; client code should be able to migrate by simply by changing import statements. Reactions? rjrjr -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: RR: Promoting RequestFactory to a higher package
GWT's i18n adds compile time checking, type checking for constants and amazing plural support. Treating with string based property bundles is a pain. Regards. - Andrés On 25 mar, 19:14, John Tamplin j...@google.com wrote: On Fri, Mar 25, 2011 at 5:34 PM, Andrés Testi andres.a.te...@gmail.comwrote: +1 for this! Are there similar plans for com.google.gwt.i18n? GWT's i18n seems inextricably tied to GWT, so I don't see any reason to move it out. Most of the classes for the infrastructure have been placed in the server package, and eventually Messages/etc will be as well (though unfortunately it will be a breaking change for non-GWT generators since annotations can't inherit from other annotations). -- John A. Tamplin Software Engineer (GWT), Google -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] How to contribute to update the spanish version of product homepage?
Hi: The spanish version of the GWT product page is out of date. The page was not updated since GWT 1.7. Can I contribute to update the page to GWT 2.1? Regards. - Andrés -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Why not Events API as part of Guava?
Since events API core in com.google.gwt.event.shared has not JSNI nor static dependencies, it could be externalized as an API isolated from GWT. Why not include it on Guava for non GWT projects? Regards. - Andrés -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Why not support GWT.create(this.getClass()) ?
Done that this.getClass() is well known at compile time, could be a
great improvement to adding support for GWT.create(this.getClass()).
For example, Guice/GIN TypeLiteralT is not fully emulated in web
mode because it's impossible to determine WTH is the type parameter T
(not support for equals(), hashCode(), toString(), etc.) . With
GWT.create(this.getClass()), TypeLiteral emulation could be defined
as:
class TypeLiteralT{
private final TypeInfoT typeInfo = GWT.create(this.getClass());
protected TypeLiteralT(){}
public String toString(){
return typeInfo.toString();
}
}
With such feature, the UiBinder boilerplate could be fixed:
class EasyUiBinderU, O implements UiBinderU,O{
private final UiBinderU, O impl = GWT.create(this.getClass());
protected EasyUiBinder(){}
public U createAndBindUi(O owner) {
return impl.createAndBindUi(owner);
}
}
UiBinderWidget, EasyDemo uiBinder = new EasyUiBinderWidget,
EasyDemo(){};
Are there technical limitations for support something like this?
- Andrés
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Why not support GWT.create(this.getClass()) ?
A sintetic protected method could be created to invoke the
GWT.create(this.getClass()):
public class A{
// created by the compiler
protected void sintetic$create(){
GWT.create(A.class);
};
public void foo(){
// replaced by the compiler
sintetic$create();
}
}
public class B extends A{
// created by the compiler
protected void sintetic$create(){
GWT.create(B.class);
}
}
On Feb 16, 10:12 pm, Ray Cromwell cromwell...@gmail.com wrote:
But this.getClass() can be a polymorphic call not know until runtime.
public class A {
public void foo() {
GWT.create(this.getClass());
}
}
public class B extends A{}
public class C extends A{}
A a0 = new A();
A a1 = new B();
A a2 = new C();
a0.foo(); // create(A.class)
a1.foo(); // create(B.class)
a2.foo(); // create(C.class)
You can easily arrange it such that there's no way to statically
determine the type of 'this'
-Ray
On Tue, Feb 16, 2010 at 5:01 PM, Andrés Testi andres.a.te...@gmail.com
wrote:
Done that this.getClass() is well known at compile time, could be a
great improvement to adding support for GWT.create(this.getClass()).
For example, Guice/GIN TypeLiteralT is not fully emulated in web
mode because it's impossible to determine WTH is the type parameter T
(not support for equals(), hashCode(), toString(), etc.) . With
GWT.create(this.getClass()), TypeLiteral emulation could be defined
as:
class TypeLiteralT{
private final TypeInfoT typeInfo = GWT.create(this.getClass());
protected TypeLiteralT(){}
public String toString(){
return typeInfo.toString();
}
}
With such feature, the UiBinder boilerplate could be fixed:
class EasyUiBinderU, O implements UiBinderU,O{
private final UiBinderU, O impl = GWT.create(this.getClass());
protected EasyUiBinder(){}
public U createAndBindUi(O owner) {
return impl.createAndBindUi(owner);
}
}
UiBinderWidget, EasyDemo uiBinder = new EasyUiBinderWidget,
EasyDemo(){};
Are there technical limitations for support something like this?
- Andrés
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
- Andrés
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: now.. afetr GWT 2.0?
+1 for databinding +1 for better grids +1 for enterprise examples, (CRUD applications) Why not isolate the event framework to use it in non GWT projects? - Andrés -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
[gwt-contrib] Re: Random Thought: Compiler transformation Sync - Async
Check this thread:
http://groups.google.com/group/google-web-toolkit-contributors/browse_thread/thread/4239559936d327e7/
On 1 nov, 11:01, Bart Guijt bgu...@gmail.com wrote:
Dear GWT'ers,
I'd like to propose a new GWT compiler transformation mechanism
involving Async calls.
I am working on a GWT API for accessing the HTML5 Database feature[1]
in an OpenSource project[2]. The W3C Web Database API[3] is translated
quite literally to a Java equivalent, involving up to 5 callbacks, in
part due to the asynchronous nature of the Database API.
Right now I am working on a higher level API involving a GWT generator
and a set of Callback interfaces with just one set of onSuccess() and
onFailere() callback methods, very similar to what the GWT RPC API
looks like.
In GWT we have lots of asynchronous callback types, almost (if not)
all having a failure path (the onFailure() method) and a success path
(the onFailure() method):
object.aMethod(..., new AsyncCallback() {
public void onSuccess() {
// success path
}
public void onFailure() {
// failure path
}}
// forward path
Q: What if we can add a transformation to the compiler which
recognizes something like the following:
try {
object.aMethod(...); // aMethod is annotated with @Async or
something
// success path} catch (Exception e) {
// failure path
}
// forward path
and transforms that to an asynchronous call?
I know it is not as simple as portrayed here (all 'forward path' code
must be called in an asynchronous manner as well, and RPC methods
would execute the 'forward path' before any 'success/failure path')
but it would nevertheless simplify GWT programming:
- Just a single RPC interface (no *Async anymore)
- Thread.sleep() - like function possible (games?)
- JDBC compatible API to the HTML5 database API (heh)
Perhaps other callbacks benefit as well.
There is a JavaScript library called Narrative JavaScript[4] which
does something like this, and introduces a 'yielding operator' to help
the NJS - JS compiler create executable JavaScript.
Please note that I am not pleading to remove Async interfaces, I like
the way they embody the Javascript nature of the runtime platform so
well. It is just that for some purposes a synchronous interface makes
more sense, and is also a bit more comprehensible to 'regular' Java
programmers.
Is any of this feasible at all? I am curious to what you guys think of
this.
Cheers,
Bart Guijt
[1] GWT HTML5 Database
API:http://code.google.com/p/gwt-mobile-webkit/wiki/DatabaseApi
[2] GWT Mobile WebKit project:http://code.google.com/p/gwt-mobile-webkit/
[3] W3C Web Database:http://www.w3.org/TR/webdatabase/
[4] Narrative JavaScript:http://www.neilmix.com/narrativejs/doc/
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Adding a DOM com.google.gwt.dom.client.Window class?
Additionally, DOM overlay types could be generalized with JSO Single
Impl interfaces.
On 17 ago, 15:16, Matt Mastracci matt...@mastracci.com wrote:
Joel,
This is definitely a can of worms! I spent some time thinking through
the some of these points. Some additional comments inline...
On 17-Aug-09, at 10:02 AM, Joel Webber wrote:
At any rate, we *do* need something like this, and now seems as good
a time as any to bring it up. In fact, there are several such
classes that need to be moved out of gwt.user.client into a more
sensible place (and others that still need to be written). What they
have in common is that they have nothing to do with widgets, but are
not core because they assume the existence of a real web browser
(as opposed to other potential Javascript targets such as Flash).
The ones that come to mind are:
Existing:
- Window
- Location
- Cookies (though maybe Document just needs its cookie property
implemented)
- Timer (this is implemented on top of Window.set[Interval Timeout]())
- History (there are both the native history object, and the GWT
history implementation to consider)
- [Incremental Deferred]Command (Smells like core, but requires
Timer to work)
One consideration this raises is that some have internal state
associated with them. For instance, both the Cookies class and
Location classes have precomputed maps of data. How can you ensure
that a service is a singleton for a given native object (or is it best
to provide this for the default window and document only)? There's
also the issue with cleaning up objects when documents/windows are
unloaded, since the lifetime of the GWT module may be significantly
longer than the windows it references. I suppose the cleanup could be
handled via some global per-window unload cleanup queue attached to a
specific window's unload handler.
Additionally, how can you handle multiple GWT modules that may
reference the same native window or document?
History and location may be useful to expose as simple JSO wrappers
over the native browser's objects. The full GWT history
implementation would probably be less useful on a window that didn't
contain a GWT module (esp. considering that newItem() is so different
on every browser).
For Timer and IncrementalCommand, I suspect there wouldn't be much
lost if they were left as global services. The only advantage to
having per-window timers that I can think of right now would be
scoping the lifetime of the timer to the window itself (is this even
consistent across browsers?). I think it might be sufficient to
create a rebind point for creating timers for different environments.
FWIW, this is the code we use to simulate Timer when running as a
Firefox extension. It would be a lot cleaner as a timer rebind and I
imagine that AIR and other JS-but-not-HTML environments would be very
similar:
window.setTimeout = function(callback, timeout) {
var timer = Components.classes[@mozilla.org/timer;
1].createInstance(Components.interfaces.nsITimer);
var handle = {timer: timer, active: 1, callback: callback};
var doNotify = function() {
manag...@com.dotspots.mozilla.extensionmanager::activeOneShotTimers--;
delete handle.active;
delete handle.callback;
delete handle.timer;
manag...@com.dotspots.mozilla.extensionmanager::safeCallback(Lcom/
google/gwt/core/client/JavaScriptObject;)(callback);
}
timer.initWithCallback({notify: doNotify}, timeout,
Components.interfaces.nsITimer.TYPE_ONE_SHOT);
manag...@com.dotspots.mozilla.extensionmanager::activeOneShotTimers++;
timers.push(handle);
return timers.length - 1;
}
New:
- Selection (this is pretty tricky, because selection on IE is so
amazingly weird)
- Others?
Selection would be very useful, even if it was limited to some simple
operations at first (exists, get text, delete, replace). The W3C
selection API is very useful, but I'm not sure if there's a compelling
use case outside of Google Wave to merit the effort required (I had
experimented with this a while back, but it's difficult to get
consistent results between webkit/gecko, let alone with IE in the
picture :)!).
There's a few miscellaneous DOM services that would be useful, such as
the DOM tree walking service and xpath functions. Neither of those is
complex enough to be consequential, so they probably wouldn't factor
into any design.
The main hold up for me has been figuring out how to move the
existing classes to a more sensible module, and precisely what that
module is. Selection and Window could arguably be considered par of
DOM (WebKit has a
[gwt-contrib] Re: UiBinder and Model View Presenter
Amir: Your answer is very interesting and detailed. Thank you very much for taking your time to answer my question. I will take a look in PureMVC. One of my big concerns is the translation of JSR 303 validations to client side. Regards. - Andrés On 13 ago, 18:36, Amir Kashani amirkash...@gmail.com wrote: For my last work project, we used Kiyaa!, a GWT library that offers its own declarative UI system (and data-binding). In addition, we used PureMVC as a very lightweight MVC-framework. If you're familiar with PureMVC, you'll know that it's much closer to MVP, as described by Ray Ryan, than it is a traditional MVC framework. They worked beautifully together. Here's our basic setup: - *Views *- these are the plain UI components represented with Kyiaa! templates. They're smart enough to display Model data and handle any UI interactions, but delegate all business logic to their Mediators. They have a Listener interface that is implemented by the Mediator, which has high-level callback methods, such as onRegister, onNewCustomer, etc rather than onClick. - *Mediator *- responsible for managing the views by facilitating communication between the View and the rest of the system. They send and receive Notifications that are handled by other Mediators or by Commands. More specifically, they provide model data to the View as it's available and handle user-triggered events from the view, etc. The mediators have NO references to any Widgets or other UI components. Their only interaction with the View is from callbacks through the defined interface and through the View's public API, which is generally fairly-high level as well. Because of this, it's easy to re-use UI components by having a different Mediator controlling the UI. - *Model* - these are your basic domain objects. They should be POJOs and have no concept of the rest of the system. Period. - *Proxy* - a Proxy's basic role is to provide a high-level API for managing the Model. Depending on the complexity of your domain object, it could be as simple as having methods such as addUser, deleteUser, etc. Or, for complex Models, such as a Word Document object, can have methods such as setTitle(), etc. In our setup, Proxys take the former role, basically encapsulating all RPC logic, implementing client-side caching, etc. You call methods on a Proxy, such as saveUser, and it sends Notifications to the rest of the system when something interesting happens. Proxy's NEVER receive notifications, however. They are not interested in the rest of the system, including the UI (or even that there is a UI), and theoretically, along with the models, should function completely on their own, making them highly reusable. - *Command* - a Command is a place where you encode complex interactions. For example, if your application has a search function, you may have a SearchCommand that 1. Receives the search query 2. Calls the appropriate Proxy to do the RPC hit 3. Loads the Mediator that will be interested in the Proxy's response, if not already loaded The SearchCommand would be triggered by a notification sent from some Mediator. The idea is to stick the logic into a re-usable Command rather than encoding it into a Mediator directly, as it may be needed from multiple places. The great part about this design and MVP is, that if we want to switch to UIBinder, all we have to do is modify the View classes. No other part of the system would have to change one-bit. Another quick note on PureMVC: it's kind of a disservice to it to call it an MVC framework, as there's very little code involved in the framework. Rather, it's a set of concepts and principles that have been very well defined, that if followed correctly, lead to highly-reusable and easily testable components. Even if you don't use the framework, I highly recommend reading their best practices:http://puremvc.org/component/option,com_wrapper/Itemid,174/ - Amir On Thu, Aug 13, 2009 at 2:27 AM, Andrés Testi andres.a.te...@gmail.comwrote: How the UiBinder fits in the MVP architecture proposed at the google I/ O talks? (http://code.google.com/intl/es-AR/events/io/sessions/ GoogleWebToolkitBestPractices.html) Regards. - Andrés --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] UiBinder and Model View Presenter
How the UiBinder fits in the MVP architecture proposed at the google I/ O talks? (http://code.google.com/intl/es-AR/events/io/sessions/ GoogleWebToolkitBestPractices.html) Regards. - Andrés --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Hello UiBinder
UiBinder is awesome!
An extra degree of decoupling, could be done by adding the next stuff
to the UiBinder interface:
public interface UiBinderU, O {
U createAndBindUi(O owner);
public static interface PairU, O{
R getRoot();
O getOwner();
}
PairU, O createAndBindUi();
}
where createAndBind() without parameters could instantiate an owner
class, enabling injection by constructor for UiField for more robust
code.
- Andrés
On 5 ago, 10:32, Ray Ryan rj...@google.com wrote:
The GWT standard widgets already have custom parsers built for them.
DockPanel, DisclosurePanel, Menubar, etc. all work just fine despite their
wonky api needs. The bug here is that you can't indulge in similar glue for
your custom widgets yet. No Google team has found that to be a problem with
their custom widgets, which is I why I felt like I could get away with
ducking that issue a bit longer.
On Wed, Aug 5, 2009 at 1:31 AM, brett.wooldridge brett.wooldri...@gmail.com
wrote:
Just a question, and a comment. First the comment. Thank you for
getting this up into the repo, in whatever state. Second, it was
commented that Adwords and a few other projects have vetted this over
the past year. How does this jibe with the deficiencies outlined?
For example, not being able to markup for DockPanel, etc? Did those
projects just have to go off-roading and create custom parsers based
on an API they knew they would eventually have to fix/rewrite?
-Brett
On Aug 5, 5:49 am, Ray Ryan rj...@google.com wrote:
I share your concern, Amir, but I'm even more afraid of a) providing an
ill
considered API for custom parsers and b) delaying 2.0. I'm pretty
confident
we can limp along without them for a dot release.
On Tue, Aug 4, 2009 at 1:36 PM, Amir Kashani amirkash...@gmail.com
wrote:
As Ray mentioned, one has a pretty simple workaround and two is pretty
uncommon. I'm a little more concerned about the third case. A few
examples
of issue with internally used widgets I've created:
- A StackPanel replacement that adds animation support. The only
workaround
I can think of is having the add() method take a StackPanelItem or
similar
that contains the header text or widget.
- TitledPanel, which supports a header, content and footer area. In
this
case, the widget could expect several calls to add, and determine the
context based on number of previous calls. This would get a bit hairy
if
headers and footers were optional, though.
These scenarios are a bit inconvenient without a custom parser, but far
from a deal breaker. The concern is that people develop a set of
hackish
workarounds that aren't easily fixed when custom parsers are supported.
- Amir
On Tue, Aug 4, 2009 at 12:47 PM, Joel Webber j...@google.com wrote:
There are three cases where custom parsers come up:1. Widgets without
a
default constructor.
2. Non-widget UIObjects that need an XML representation.
3. Panels that need more than the default add() method to deal
properly
with child widgets.
The former is usually pretty easy to work around, and it seldom comes
up
much in practice (I think it came up for MenuBar, because it wants its
'direction' as an invariant -- that wasn't even a good design anyway).
The second case doesn't come up all that often, but it's important for
menus and trees.
The third case is the most problematic. Take DockPanel, for example:
It's
really not going to be able to do anything useful if you just call
add() on
it, because it doesn't know where to put the child. These sorts of
panels
need extra attributes or elements to specify where to put children.
On Tue, Aug 4, 2009 at 3:42 PM, Amir Kashani amirkash...@gmail.com
wrote:
What are the limitations for a Widget developer without a custom
parser?
I've only begun to look at the code, but it seems like it'll still be
possible to use a custom widget albeit with cumbersome markup.
- Amir
On Tue, Aug 4, 2009 at 12:35 PM, Joel Webber j...@google.com
wrote:
Ok, then we'll need to be pretty clear about that in the
documentation,
because it's a pretty serious landmine (i.e., in that existing
projects
could easily have some widgets that couldn't be directly used with
UiBinder
without hackery). As an example, I'm going to have to add some
parsers for
LayoutPanel, et al, because they have somewhat unusual construction
semantics.
On Tue, Aug 4, 2009 at 3:31 PM, Ray Ryan rj...@google.com wrote:
I was thinking 2.1, actually.
On Tue, Aug 4, 2009 at 12:31 PM, j...@google.com wrote:
On 2009/08/04 18:50:55, Ray Ryan wrote:
On 2009/08/04 17:44:38, Ray Ryan wrote:
A question for the group: the stuff under rebind and parsers
should
not be
considered public API, it's just not ready for that. Is javadoc
to
that effect
[gwt-contrib] GWT 2.0 and JSNI instantiations
Currently I am writing a generator to produce class mappers. Mapped
classes must contain a default constructor like the current RPC
serializable classes. Since the new deRPC can instantiate classes
without invoking static constructors: ¿Will the JavaScript
instanciator be available from JSNI in GWT 2.0? For example:
class Foo{
// no default constructors
public Foo(String name){
}
}
private Foo newRawInstance()/*-{
return @com.mycompany.Foo::instantiate();
}-*/;
Thanks in advance.
- Andrés
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Reduction of JavaScript class declarations.
Having a function like:
function d(){
return function(){};
}
... class declarations like:
function Foo(){}
... could be reduced to:
var Foo=d()
... reducing compiled code by 5 characters for each declaration.
- Andrés
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: Reduction of JavaScript class declarations.
Even more code reduction could be done declaring all vars in the same
place:
function Foo1(){}
function Foo2(){}
function Foo3(){}
... could be reduced to
var Foo1=d(),Foo2=d(),Foo3=d();
- Andrés
On 2 jul, 19:11, Andrés Testi andres.a.te...@gmail.com wrote:
Having a function like:
function d(){
return function(){};
}
... class declarations like:
function Foo(){}
... could be reduced to:
var Foo=d()
... reducing compiled code by 5 characters for each declaration.
- Andrés
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Injecting instances from generators to generated code.
A common situation using generators is write instantiation code to
inject instances of non-generated classes. For example:
String newFooExpr(String name){
return new + Foo.class.getName() + ( + name + );
}
String initializationExpr(Class? cls, String varName, String expr){
return cls.getName() + + varName + = + expr;
}
String fooReferenceExpr = foo;
String fooInitializacionExpr = initializationExpr(Foo.class,
fooReferenceExpr, newFooExpr(hello));
Later, fooInitializationExpr is injected in the generated source code.
This approach is easy to write for light object trees, but becomes
complex with deep trees.
Since serialization is a way to freeze an object tree for further
consumption, such mechanism could be used to inject instances from
generators to generated code. For example, being Foo serializable, and
having an InstancePool in GeneratorContext:
Foo foo = new Foo(hello);
String fooReferenceExpr = generatorContext.getInstancePool().add(foo);
InstancePool.add() adds an instance to the pool and returns a
generated global reference name. When all the generators were invoked,
the InstancePool is serialized in a static context, where the
instances can be referenced by generated reference names.
This approach could allow frameworks like GIN to be fully compatible
with Guice Modules, enabling injection of instances, scopes, etc..
How silly is this idea?
Thanks in advance.
- Andrés
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Re: eliminate dynamicCast for generics, or all?
Ray:
What happends if you extends ArrayList to avoid generics?:
class RangeAxisArrayList extends ArrayListRangeAxis{}
- Andrés
On 23 ene, 16:52, Ray Cromwell cromwell...@gmail.com wrote:
Here's the scoop. I changed a field in Chronoscope from RangeAxis[] to
ListRangeAxis and suffered ~50% performance regression. An Axis is a class
responsible for mapping values in the range [low, high] to [0,1], among
other things, so it is a hot class/method in Chronoscope. After profiling, I
noticed the method was no longer being inlined, and a huge number of calls
to dynamicCast/canCastUnsafe appeared. This brings to mind two
optimizations:
1) if a method's return type is covariant in a generic type, do not insert a
cast or cast check. Assume that the method *will* return objects of this
type at the callsite.
2) eliminate dynamicCast/canCastUnsafe altogether. These methods only exist
to throw class cast exceptions. I can't believe that there's any code that
actually expects these exceptions and depends on them being thrown except
perhaps unit tests. Anyone running unit tests or UI tests in hosted mode
will get these exceptions during development, so it seems the only use case
might be web-mode unit tests.
But for production deployed code, dynamicCast/canCaseUnsafe/setCheck/et al
seem to just be bloat and a performance hit to boot. Can we get a compile
mode that removes them? Maybe an -XX method, or some other mechanism which
says I want potentially unsafe, but super fast code?
-Ray
--~--~-~--~~~---~--~~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~--~~~~--~~--~--~---
[gwt-contrib] Will runAsync() be a right choice for modular projects?
I know this thread should be posted in the GWT developer group, but since runAsync() is planned for future releases, I think this group is a better place to post my question. I'm involved in a modular project, distributed as a core with dependencies, where the customer pays for aditional features (modules). Modules have UI interface and server logic, and are distributed as individual jars. I know the need to compile all modules in the same compilation process, but I want to know if is this a right architectural choice. - Andrés --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Relax JSO restrictions?
Sorry Joel, it was a typo. Should be com.google.gwt.xml.client.* instead of com.google.gwt.dom.client.* - Andrés On 15 dic, 14:31, Joel Webber j...@google.com wrote: @mP: I completely agree that it's worth seeing if these things can be done *without* changing the compiler. In this case, though, I'd have to agree with your Cons section, that it's pretty weird to have two versions of a class. Makes debugging really suck, too :) @Andrés: This would indeed make it possible to implement org.w3c.dom.* directly (though it's a little bit of a minefield, because anybody else trying to implement those interfaces in the same app would likely trip the one-implementor restriction). However, it's not entirely clear to me how this could be used to optimize the code in c.g.g.dom.client.*. Am I missing something here (I hope so, because I just love a good optimization!)? joel. On Fri, Dec 12, 2008 at 10:28 PM, Andrés Testi andres.a.te...@gmail.comwrote: Or even, implementing org.w3c.dom.* natively ;-) On 13 dic, 00:21, Andrés Testi andres.a.te...@gmail.com wrote: Great news! This will allow a faster implementation of com.google.gwt.dom.client.* On 12 dic, 20:05, Bruce Johnson br...@google.com wrote: Ray, great timing. Bob was just talking about having started a patch to allow this. @Bob: care to comment? On Fri, Dec 12, 2008 at 6:01 PM, Ray Cromwell cromwell...@gmail.com wrote: So, I've got these JSON formats that I use both in my Android code and my GWT code. I originally implemented them as Overlay JSOs, and there are classes that consume these OverlayJSOs to configure other parts of the app. However, this makes the consumption code (which is really quite generic and portable) unable to run in non-GWT environments. Thus, I need the consumption code to be able to consume interfaces instead. I refactored the Overlay JSOs into interfaces (e.g. JsonDataset) and provided a wrapper implementation (GwtJsonDataset) that uses private overlay types. I then implemented a J2SE version which uses the org.json APIs, which runs in the servlet/android versions. However, it slightly annoys me that: 1) I have to use a wrapper, so all of the generated consumption code looks like foo.jso.range instead of foo.range 2) There is never more then one implementation of the interface active in a GWT compile, so it is trivially type-tighten-able to the implementation class. Couldn't the JSO restrictions checker, as a first pass, visit every instantiation of interfaces implemented by the JSO, and verify that only a single concrete type of the interface is instantiated? This would allow JSOs to implement interfaces as long as there is effectively only one implementation active. I'm thinking the logic would go something like this: for each interface of JSO lookup all implementing classes in oracle for each implementating class find all types instantiated if 1, error Now, this can change subject to pruning passes, but I would settle for the restriction that only one concrete instantiation must exist prior to DCE/Pruning. -Ray --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
[gwt-contrib] Re: Relax JSO restrictions?
Great news! This will allow a faster implementation of com.google.gwt.dom.client.* On 12 dic, 20:05, Bruce Johnson br...@google.com wrote: Ray, great timing. Bob was just talking about having started a patch to allow this. @Bob: care to comment? On Fri, Dec 12, 2008 at 6:01 PM, Ray Cromwell cromwell...@gmail.com wrote: So, I've got these JSON formats that I use both in my Android code and my GWT code. I originally implemented them as Overlay JSOs, and there are classes that consume these OverlayJSOs to configure other parts of the app. However, this makes the consumption code (which is really quite generic and portable) unable to run in non-GWT environments. Thus, I need the consumption code to be able to consume interfaces instead. I refactored the Overlay JSOs into interfaces (e.g. JsonDataset) and provided a wrapper implementation (GwtJsonDataset) that uses private overlay types. I then implemented a J2SE version which uses the org.json APIs, which runs in the servlet/android versions. However, it slightly annoys me that: 1) I have to use a wrapper, so all of the generated consumption code looks like foo.jso.range instead of foo.range 2) There is never more then one implementation of the interface active in a GWT compile, so it is trivially type-tighten-able to the implementation class. Couldn't the JSO restrictions checker, as a first pass, visit every instantiation of interfaces implemented by the JSO, and verify that only a single concrete type of the interface is instantiated? This would allow JSOs to implement interfaces as long as there is effectively only one implementation active. I'm thinking the logic would go something like this: for each interface of JSO lookup all implementing classes in oracle for each implementating class find all types instantiated if 1, error Now, this can change subject to pruning passes, but I would settle for the restriction that only one concrete instantiation must exist prior to DCE/Pruning. -Ray --~--~-~--~~~---~--~~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~--~~~~--~~--~--~---
