On Wed, Apr 8, 2009 at 2:38 AM, Lex Spoon <[email protected]> wrote:
> On Mon, Apr 6, 2009 at 8:48 PM, Freeland Abbott <[email protected]>
> wrote:
> > There's no special recursion I had to provoke; if you put logging in
> instead
> > of my short circuit, I think DynaTable reconsiders java.lang.String
> > something like 23 times before reaching TIC shortcircuits. My patch
> saved
> > almost 10% time for DynaTable, I think due to this earlier shortcircuit.
> > (Sorry, should have bragged on that in the first posting.)
>
> Wow, great! Hopefully we can make this same thing happen with the TIC
> shortcut. Probably a TIC-based short circuit could be inserted at the
> same place a visited shortcut is.
>
My working copy still gets "I have visited information, but not TIC
information" at the shortcut point, apparently only for parameters of
parameterized type (that is, visited has an entry about "E extends
FooClass", but the matching tic.isDone() return false at that point). I
haven't yet had a chance to work through why that is, but I'm suspicious
whether the parameterization even gets its own TIC entry (no reason it
can't, right?) and if so, whether that is treated independently enough of
its parent class.
Oh, I overlooked the "reached via" part. That means the information
> is still there, which was my main concern.
>
> I do still wonder about the exact user experience reading one of these
> logs. Could you post one the next time you have one handy?
>
> It seems like they will see, "Foo is not instantiable and has no
> instantiable subclasses". To find out the subclasses, they have to do
> a search to find all the "reached via Foo". It seems slightly better,
>
Actually, what they get is "LeafClassOne is not default instantiable (it
must have a zero-argument constructor or no constructors at all) and has no
custom serializer. (Reached from SomeTypeNamedInYourInterface)", and
"LeafClassTwo is not default intantiable ... (Reached from ...)", with no
mention of intervening type hierarchy: only the leaves are complained
about. But they get "AbstractParent has no concrete subtypes," rather than
"AbstractChild is not concrete (Reached from AbstractParent.)" for that
one, so it's perhaps a bit inconsistent in how it works out. Arguably
helpful ("this one is wrong" where possible, "there's nothing to look at
here" otherwise), but inconsistent.
At least that's what I remember; I've broken my workspace on your other
comments, so I'll have to fix that or patch the changes into a clean
workspace to reproduce. ;-)
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
