NOTE: The current preferred location for bug reports is the GitHub issue tracker.
Bug 662 - Dynamically populate CppVisitor.CLASS_NAMES
Dynamically populate CppVisitor.CLASS_NAMES
Classification: Unclassified
Component: HTML parser
All All
: P2 enhancement
Assigned To: Ben Newman
Depends on:
Blocks: 660
  Show dependency treegraph
Reported: 2009-10-03 11:56 CEST by Ben Newman
Modified: 2009-10-03 11:56 CEST (History)
1 user (show)

See Also:

Preliminary patch (2.96 KB, patch)
2009-10-03 11:56 CEST, Ben Newman

Note You need to log in before you can comment on or make changes to this bug.
Description Ben Newman 2009-10-03 11:56:30 CEST
Created attachment 117 [details]
Preliminary patch

The japa java parser doesn't expose enough information to distinguish between static field accesses against class names (e.g., NamedCharacters.NAMES) and normal field accesses against objects (e.g., attributes.addAttribute).  While this distinction makes no syntactic difference in Java, C++ joins the former with "::" and the latter with "->" or ".".

Currently CppVisitor disambiguates these two cases by referring to CppVisitor.CLASS_NAMES, a static array of class names known to be used in the htmlparser implementation:

  private static final String[] CLASS_NAMES = { "AttributeName",
          "ElementName", "HtmlAttributes", "LocatorImpl", "MetaScanner",
          "NamedCharacters", "Portability", "StackNode", "Tokenizer",
          "TreeBuilder", "UTF16Buffer" };

This does not seem ideal, since the list must be updated whenever a new class is added, and the class names are htmlparser-specific (whereas CppVisitor is theoretically a generic visitor).

It appears feasible to populate this list dynamically (see patch).  The correctness of this patch depends on the assumption that all ClassOrInterfaceDeclaration AST nodes have been visited before sClassNames is first examined.  This assumption appears to hold, even when constructs requiring sClassNames appear before the relevant class declaration.