On Thu, Oct 2, 2008 at 4:56 PM, Lex Spoon <[EMAIL PROTECTED]> wrote: > 1. Is there any reason to store all correlates as strings? The
I agree that the final API provided by the Correlation type should be more structured than just a String, but I don't think that it should hang on to the AST node. I was going to wait to expand the Correlation API until I talked to Katherin next week about what information would actually go into the visualizations, but I imagine that it would have String getters for package, type, and field. > 2. Attaching a method to its overrider parent seems to mix two > ... > anyway, once runAsync is merged in. Given this, is there any further > reason to have method override imply ancestry? It seems to dilute the > information that SourceInfo ancestry can uniquely provide. Will the type oracle still be available during the Link phase of the compiler? If so, I'll remove all of the override information from SourceInfo. If the oracle won't be available, I'll add an "overrides" relationship to SourceInfo to clarify the meaning of ancestry. > - Why are there synchronized methods in SourceInfo? In particular, > why are some synchronized but not others? Reads and writes to mutable fields were made synchronous. In practice, with the current structure of the compiler, there's no reason to make them thread-safe. I'll remove the synchronization. > - It would be really nice to have utility methods that find and return > the primary and secondary correlates on a specified axis. If I > understand correctly, a caller must currently search through the > return value of getCorrelations or getDerivedCorrelations. Easy enough. -- Bob Vawter Google Web Toolkit Team --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
