Reflection-Repository Trade-offs

Neither approach is adequate in all circumstances. Here are several trade-offs to consider:

• Completeness. A reflection-based approach precludes browsing code that is not compilable. Repositories only require the code to be reasonably parsable, and they can make broad assumptions about incomplete portions.

• Coupling. Reflection is closely associated with the programming language. As a result, there is tight binding between reflection facilities, client code, and the run-time environment. A repository, in contrast, can be more loosely coupled to its clients. One result is that testing a client apart from the repository is generally easier than testing it apart from the reflection machinery.

• Semantic mismatch. A repository may have facilities beyond reflection, such as versioning and concurrency control, that are overkill for simple clients like the class browser, which has no editing or versioning capabilities. The repository doesn't justify its cost for such clients. Conversely, a repository that offers no more than a subset of a language's reflection facilities has limited use in that language.

• Inconsistency. Information about a class might be different depending on whether it was obtained from a repository versus reflection. If a program loads a class dynamically, reflection may know about it but not the repository. The repository might provide more accurate information when someone else changes the class.

• Inflexibility. If you have a tool designed to use reflection, can you run it without a compiler? If the tool works with files, can you retarget it to use reflection? How easy is it to divorce class-browsing facilities from the mechanisms for extracting and managing source information? The easier all that is, the more flexible and reusable the tool.

Making the meta-information source pluggable makes it easy to choose one approach and change your mind later. It can also offer the best of both worlds.