When interface rules or overriding rules are employed the TARGET class mentioned in the CLASS or interface rule may differ from the TRIGGER class into which the rule is injected. For example, when a rule is specifies INTERFACE List the TARGET class is List but the TRIGGER class may be LinkedList, ArrayList or some other implementation. At present the type checker type checks the rule using the TRIGGER class to identify the type of $this.

This allows such rules to profit from the opportunity to refer to members that may belong to the TRIGGER class but not to the TARGET class. For example, the rule may invoke $0.pop() which is legitimate for class LinkedList but is not a method of interface List. This does not risk type errors because such uses are type checked. In the case of, say, class ArrayList the type checker will disable rule execution because $this does not implement method pop().

The down side of operating on $this at the most specific level in the type hierarchy is that the TRIGGER type is sometimes inaccessible – it may be a private type or an inner type. In such cases, it would be preferable to type check and execute operations on $this at the more abstract level defined by the TARGET type. Indeed, arguably this ought to have been the default typing model employed by the type checker with the use of the TRIGGER type being a configurable option.

It would still be useful if the choice of type for $this could be configured albeit retaining the default choice as the TRIGGER type in order to avoid legacy problems. The syntax proposed is to allow a new clause

AS TARGET|TRIGGER

which can be inserted either at the top level in a script (setting a default for subsequent rules) or in a rule body (specifying the setting for that specific rule). In the latter case the clause should be written between the AT and IF clauses. Assuming that it is feasible, the type checker should adopt the corresponding type for $this with consequential effects on the resolution of related types and members.