On Thu, Apr 16, 2009 at 11:13 AM, Freeland Abbott <[email protected]> wrote: > On Tue, Apr 14, 2009 at 1:30 AM, Lex Spoon <[email protected]> wrote: >> >> Can you verify that the same RPC decisions are being made? For >> example, does the code size look about the same, and the RPC policy >> files exactly the same? In particular, I'm worried about the new TICs > > RPC files are identical for benchmarkviewer and dynatable, which is what I'd > been checking. Aggregate permutation output totals the same number of > bytes, and (probably more significantly) hashed names are identical for the > leading and trailing several digits for the same two programs. > Both samples have parameterized collections, although I'm not so sure about > wildcarding... I can make a toy sample to explore that.
Cool! That's convincing. >> being added for things like wildcard types and type parameters. After >> a few minutes of poking, I don't see where those are weeded out, and >> indeed I see some places where a type parameter is quietly replaced by >> its upper bound. If there are any differences, a simple way to prevent > > Where is there a replacement that's not in the original? I didn't intend to > make such changes; it seems not to be impacting my two samples or the test > case, but that may say more about the sufficiency of my tests than the > correctness of my patch. :-/ > In terms of weeding out, though, what I did was to try to be careful about > having new TICs not be "instantiable," but instead use > "hasInstantiableSubtypes." So I expect to have new TICs around wildcards > and type parameters, but for their direct instantiability to be unchanged. That must be it. There are new TICs, but they are neither instantiable nor field serializable. >> I wouldn't expect TypeExposureComputer to need to report any problems. >> Did you run any any cases where it should? Barring an argument to the > > Not directly, no, but it's needed for pass-through to e.g. > STOB.shouldConsiderFieldsForSerialization by way of > computeIndirectExposureCauses(). In that case it seems better to pass in an empty problem report, as is done for similar methods that expect a logger. > I think I'd rather land and reset, if it's okay with you. Although it's > obviously not hard to move the problems to TypeInfoComputed, that doesn't > simplify, at least not w.r.t. the problems parameter, when adding problems > in static methods (perhaps by way of TypeInfoExposureComputer, yes). No, I meant the overall thing. Certainly let's do it later. I don't need to rereview these changes, but please do have TypeExposureComputer log to throw-away ProblemReports rather than live ones. Unless you see a reason it should be logging out to the user, of course. Lex --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
