I think it's more like no one's brain is large enough to keep full cognition of 3 complete AST APIs concurrently, and the GWT team lacks resources to have a guy who's sole purpose is to own JDT->GwtAST. Looking at the comments, the JDT AST isn't exactly a pleasure to work with either. There's comments in the source for non-obvious stuff, but it still requires indepth understanding of JDT, and I don't know if I have enough brain cells to spare. :)
Scott's brain on the other hand is a different story. You'll note from photos his skull is about 20% larger than the average persons. :) -Ray On Thu, Jan 29, 2009 at 11:50 PM, David <david.no...@gmail.com> wrote: > Sounds like a maintenance problem! Time to refactor ? > > On Fri, Jan 30, 2009 at 1:14 AM, Scott Blum <sco...@google.com> wrote: >> >> Nobody understands GenerateJavaAST. We just hack on it until it does the >> right thing. :) >> >> On Thu, Jan 29, 2009 at 6:59 PM, Ray Cromwell <cromwell...@gmail.com> >> wrote: >>> >>> I think it would be useful to, but on second look, there appear to be >>> a number of different contexts in which JCastOperation is generated by >>> the compiler, rather than present in the original source: >>> >>> 1) when converting JDT expressions involving generics >>> 2) when type-tightening >>> 3) when simplifying expressions >>> 4) in MethodInliner when cloning parameters >>> 5) when autoboxing (primitive casts) >>> 6) when normalizing JSOs >>> >>> So it seems there are three classes of casts. Those authored by the >>> user, those generated for generics due to type-erasure, and those >>> generated during optimization. >>> >>> Scott, >>> I gotcha now. I see obvious places to do this in >>> processExpression(MessageSend x) and JExpression >>> processExpression(FieldReference x), but due to my lack of JDT >>> knowledge, I don't quite understand what's going on in the >>> processExpression(QualifiedNameReference x) and >>> processExpression(SingleNameReference x) routines, so I'm not sure if >>> anything has to be done in those. If follow Bruce's suggestion and >>> simply tag JCastOperations based on their reason for insertion, it >>> seems conceptually simpler to remove those in a latter compiler pass, >>> and avoid risking breaking GenerateJavaAST, which honestly is code in >>> which I don't understand the specifics of a lot of what's going on. >>> >>> -Ray >>> >>> >>> On Thu, Jan 29, 2009 at 1:56 PM, Bruce Johnson <br...@google.com> wrote: >>> > I'm long since unfamiliar with the specifics of that code, but it seems >>> > like >>> > designating a JCastOperation as "generated by the compiler" would be >>> > useful, >>> > then during actual code generation, you'd just avoid emitting the >>> > runtime >>> > cast code. >>> > >>> > On Thu, Jan 29, 2009 at 4:52 PM, Ray Cromwell <cromwell...@gmail.com> >>> > wrote: >>> >> >>> >> Scott, >>> >> Do you mean the JMethodCall produced by >>> >> CastNormalizer.ReplaceTypeChecksVisitor? I looked at doing this, but >>> >> it seems by the time you get to this stage, you know longer can tell >>> >> the difference between a cast inserted automatically because of >>> >> generics, or a cast inserted by the programmer (from JDT >>> >> CastExpression). I suppose an extra field could be added to >>> >> JCastOperation to tell if it came from an automatically generated >>> >> cast, but perhaps this is not what you were thinking of? >>> >> >>> >> >>> >> -Ray >>> >> >>> >> >>> >> On Thu, Jan 29, 2009 at 1:23 PM, Scott Blum <sco...@google.com> wrote: >>> >> > On Thu, Jan 29, 2009 at 3:41 PM, Ray Cromwell >>> >> > <cromwell...@gmail.com> >>> >> > wrote: >>> >> >> >>> >> >> If I add a check for an option, and make this routine a no-op, is >>> >> >> it >>> >> >> going to work, or break something? Alternatively, I can replace >>> >> >> calls >>> >> >> to canCastUnsafe/dynamicCast with no-ops further down in the >>> >> >> processing and get rid of all casts. >>> >> > >>> >> > This is going to break stuff because the return type of the called >>> >> > method >>> >> > will be seen to be Object without the cast, which will destroy >>> >> > TypeTightener's ability to optimize, and generally the AST won't be >>> >> > valid >>> >> > without it. What you would need to do is modify the JMethodCall >>> >> > being >>> >> > produced to override the return type of the target JMethod given >>> >> > your >>> >> > better >>> >> > generic information. >>> >> > Scott >>> >> > >>> >> > > >>> >> > >>> >> >>> >> >>> > >>> > >>> > > >>> > >>> >>> >> >> >> > > > > > --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
