LGTM. Just be sure to add the test class that you had in
http://gwt-code-reviews.appspot.com/161802
http://gwt-code-reviews.appspot.com/225801
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Rietveld really wants to create a new issue rather than adding a patch
here. I'm not sure why. Anyway, the updated version of this patch is
here:
http://gwt-code-reviews.appspot.com/227801
http://gwt-code-reviews.appspot.com/161802
--
Trying again:
http://gwt-code-reviews.appspot.com/220802
http://gwt-code-reviews.appspot.com/161802
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
LGTM. I like the UnitTestTreeLogger, didn't even know it existed.
http://gwt-code-reviews.appspot.com/220802
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Yeah.. just remember someone might also do funky things with the passed-in
class literal, like .getName() or == Foo.class. So most likely it needs to
wrap the real class object and generate unbox code if you use the literal
itself.
On Thu, Mar 11, 2010 at 2:28 AM, Ray Cromwell
On Tue, Mar 9, 2010 at 2:28 PM, sco...@google.com wrote:
That being said, there's an inconsistency between this and the the
existing error reporting architecture. The general paradigm is that all
potential user-errors are caught by the time GenerateJavaAST finishes.
These lines in
Hi Lex,
Thanks for the very thoughtful write-up. You make many excellent points,
and I especially agree with you about how much it sucks to work with
Eclipse's internal AST, and the points about how it's less code and easier
to understand if you mix the checking and transform code together, for
Generally speaking, this sounds like a good direction. I am becoming more
fond of things that can be checked locally.
On Wed, Mar 10, 2010 at 7:02 PM, Ray Cromwell cromwell...@google.comwrote:
Can I suggest a middle-ground philosophical approach for the future?
In the normal javac world,
If you do as Ray suggests and implement @IsLiteral, please make it
work transitively. ie. make this work:
public static T extends IMarker T foo(@IsLiteral ClassT clazz) {
return (T)GWT.create(clazz);
}
The above example is not particularly compelling, but it's the best I
can do right now.
You could do just the error checking transitively, without needing dataflow.
It's the implementation that gets tricky...
On Wed, Mar 10, 2010 at 8:41 PM, Ray Cromwell cromwell...@gmail.com wrote:
Transitivity would require dataflow which I think is more than what is
being proposed at the
True, but it kind of violates the idea that the error checking should
strive for locality. Actually, as long as the annotations are
replicated, it can stay local.
Consider:
public Type makeIt(@IsLiteral Class? clazzLiteral) {
return GWT.create(clazzLiteral);
}
When visiting makeIt(), you can
On Wed, Mar 10, 2010 at 10:51 PM, Ray Cromwell cromwell...@gmail.comwrote:
True, but it kind of violates the idea that the error checking should
strive for locality. Actually, as long as the annotations are
replicated, it can stay local.
Consider:
public Type makeIt(@IsLiteral Class?
On Wed, Mar 10, 2010 at 9:48 PM, Scott Blum sco...@google.com wrote:
Well, you could conservatively throw out these cases and require the
annotation to carry forward. But to me the real problem in our current
compiler is
makeIt(Foo.class);
makeIf(Bar.class);
public Type
Mostly LGTM, and a definitely improvement.
That being said, there's an inconsistency between this and the the
existing error reporting architecture. The general paradigm is that all
potential user-errors are caught by the time GenerateJavaAST finishes.
These lines in JavaToJavaScriptCompiler
I should have mentioned.. one of the important reasons to do the error
checking early (and on the JDT AST rather than the GWT AST) is that at
some point we want to share all user-error validation code with the
Google Eclipse Plugin, and it'd be good if that migration is as painless
as possible.
I left out a file. Creating a new issue.
http://gwt-code-reviews.appspot.com/162801
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
Can you review this, Ray?
In trunk, the compiler generates an internal compiler exception if
runAsyncCode is called with something other than a class literal as an
argument. This fixes that problem, and while at it, updates all the
other error messages in ReplaceRunAsyncs to be more
17 matches
Mail list logo
