The Reflection Engine

The reflection engine is the part of the Noos interpreter that assures the reflection principles hold.

The reflection engine in Noos assures that:

1. when a method is reflected down to the f feature of the referent the bindings are appropriate,
2. that if that method fails, backtracking is engaged and another method--of the remaining non-failed methods--will be reflected down.
3. If there is a partial order of preferences among the alternative methods, the method reflected down is such that no other method that has not failed is preferred to it.

Since a method can have subtasks, and each subtask may have several alternative methods, the reflection engine assures the possible subtasks method combinations are tried following the local preference orderings until a solution is found. And it also assures that all these combinations have been tried before declaring a method to fail and then proceed to select the next preferred alternative method for the task at hand. Moreover, the reflection engine assures that when evaluating a method that has been reflected down, all subtasks alternative methods will be selected respecting their local preference orderings. As we saw, features of a method can be also references--say (>> phone of John). Now, one of these references can be to a certain feature that has a metalevel with several alternative methods. In this situation the reflection engine assures also that all alternative methods in that feature are selected and reflected down following the local preference order until a solution is found or all alternatives have failed. In summary, the reflection engine can be seen as a backtracking engine plus the insurance that the solution found will be the best according to the combination of local preference orderings (cf. Chapter 5). However, the the reflection engine also assures other properties explained in Chapter 4 and the base-level metalevel mapping introduced in the next section on reification.