On 2011/02/17 05:22:16, jbrosenberg wrote:
Scott makes sense, however, would it not also make sense to have a
signature
that can also used by generators to determine whether a type has
changed (and
prevent the need for an alternate signature being maintained for that
purpose)?
Currently, we have a dumbed down version of generating a signature
from the full
bytecode (in JRealClassType). That would benefit from an asm based
signature
that only looks at api level structure....Perhaps this present code
could be
modified to alternately accept a flag to consider annotations as well,
if
desired.
I'm wondering if handling the case where some methods have been
re-ordered in a
source file is worth incurring the overhead of sorting and managing
multiple
StringBuilders, etc. This could add up if we have a large number of
classes to
consider, etc. I'm not sure how often a source file has some
fields/methods
re-ordered, vs. other api changing edits, or how important it is to
seamlessly
handle that case (I think the user expects some recompiling when
editing code).
Maybe it's not too expensive though (in which case I'll go jump off a
cliff)?
How long on average does it take to generate a signature with this
code? I
think that should be a design consideration too. Eric, do you have
any timing
numbers on that?
I've been thinking along the same lines, that we should have a good way to compute for typeoracle. I haven't done any performance measurements. My thoughts were that we might be able to share some code, but the type oracle hash would be interested in different things than the class compile dependency. http://gwt-code-reviews.appspot.com/1359802/show -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
