| ||
Advanced Issues: Using a Virtual Prefix |
A virtual pattern is not dynamic in the same way a pattern variable is, because it never changes during the life-time of its enclosing object. On the other hand, it is not possible in general to detect whether any given syntactic context has a most specific perspective on a given virtual, so many usages of a virtual pattern must be analyzed statically under the assumption that it could be any specialization of the statically known type. Hence, inheriting from a virtual pattern generally means inheriting from a pattern which is not known before run-time. The usage of a virtual pattern as a super-pattern is quite familiar, it's much like using ordinary specialization, apart from the fact that gbeta supports it and traditional BETA does not. One difference which emerges when using it, however, is that the further-binding contributions must often be merged from more than one source. This was actually the first source of inspiration for the type combination mechanism in gbeta. Example 8
This example shows a tiny container data-structure hierarchy in
which an iteration method
Example 9Another typical way to use a virtual pattern as a super-pattern is for error handling. Again, this is a situation which is well-known by BETA programmers: A certain method ought to be virtual because it is a method in a hierarchy where different patterns provide different implementations. At the same time, the method must be non-virtual, because the error handling creates a need for using the method as a super-pattern. A typical example is along the lines of:
Here's a runnable example illustrating the concept:
The next section presents the underlying mechanism for type combination, now that we've seen several more or less perspicuous examples of how it works. |