Apex Code Development You need to sign in to do that
Don't have an account?
Scott Wells Gaps in the Tooling (and Partner/Metadata) APIs for building a comprehensive symbol table
I'm very far along on an IDE plugin for Apex development and one of its features is generation of an offline symbol table for completion, reference navigation, etc. After a significant effort I think I've managed to put together the most complete symbol table possible using the Tooling, Partner, and Metadata APIs including the "private" APIs used by the Eclipse plugin, e.g., ApexClassIdentifier. At this point there are a few things that are still missing to complete it, though, and I'm hoping they're available and I'm just not finding them. Any insights on these is greatly appreciated!
- Base class information - The Tooling API supplies the names of implemented interfaces but not the base class, in particular for System classes and classes from installed managed packages. Without this information I can't reliably provide information about base classes such as potential completions, navigation, polymorphic type behavior, etc. The best workaround I have for this is to manually supply this information for the System classes in my plugin, but that still doesn't help with classes from installed managed packages that extend other classes.
- Type declaration information - The Tooling API's "completions" resource provides a decent amount of information about the System types, but one thing it doesn't include is the actual declaration type, i.e., class vs. interface vs. enum. I'm able to infer that a declaration is an enum because it has a very specific signature that includes a values() method that returns a list of the same type, but I have no way to determine which declarations are interfaces. As a result, I can't determine whether a type should be valid for extension vs. implementation in local classes.
- Enum constants - The Tooling API's ApexClass information doesn't include enum constants. This is less of an issue because in general these files would typically exist in the local filesystem, but in the case that the developer only keeps a subset of the org's unpackaged classes in the local filesystem, the API leaves a gap in the symbols it provides. I have a workaround for this that allows me to get enum constants for all enums that are public visibility or higher, but it seems like an odd omission.