Uploaded image for project: 'Byteman'
  1. Byteman
  2. BYTEMAN-325

Allow enforced use of TARGET vs TRIGGER type at type check

    XMLWordPrintable

Details

    • Feature Request
    • Resolution: Done
    • Major
    • 4.0.18
    • 3.0.6, 4.0.1
    • Parser/Type Checker
    • None

    Description

      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.

      Attachments

        Activity

          People

            rhn-engineering-adinn Andrew Dinn
            rhn-engineering-adinn Andrew Dinn
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: