Motivation

The need for pluggable reflection arises as soon as you have more than one source of meta-information. Consider for example the overlap between reflective facilities and source code repositories. Both manage information about classes and their relationships, and both aid in the software development process--they can make changing, tuning, and debugging your program a lot easier.

Yet reflection and repositories have obvious differences that complicate interoperability. Ideally we could ignore such differences, choose either approach, and switch between them freely; the origin of reflective information would be transparent to clients. But in practice, the reflection interface and its implementation are strongly coupled. Again, the code that uses reflective information is the same as the code that accesses the reflective representation.

Suppose you are writing a tool that processes source code, such as a class browser. It requires services found in both the reflection interface and the class repository interface at your disposal (that is, the intersection of those interfaces). You therefore have a choice--you can get class information from either source. Your browser can compile and load classes and then use reflection to reveal their structure, or it can parse the class source, store the information in the repository, and query the repository for the same information (Figure ).

Figure: Reflection-repository duality

duality.ps