Class OperationInstr

java.lang.Object
org.ek9lang.compiler.ir.instructions.OperationInstr
All Implemented Interfaces:
Comparable<OperationInstr>, INode
public final class OperationInstr extends Object implements INode, Comparable<OperationInstr>
An operation on some sort on a Construct. By this we are talking about methods and operators, but also constructors and 'init' operations.

For example in the case of normal classes/traits/components etc. this would just be a method.

In the case of a function it would also be a method but with a name of 'call' and the normal function signature would be applied (to the 'call' operation).

  • Constructor Details

  • Method Details

    • getBody

      public BasicBlockInstr getBody()

    • setBody

      public OperationInstr setBody(BasicBlockInstr basicBlockBody)

    • getSymbol

      public ISymbol getSymbol()

    • getBridgeReturnTypes

      public List<String> getBridgeReturnTypes()
      The fully qualified return types of the parent declarations this operation overrides with a NARROWER (covariant) return - set by IR generation (phase 7, CovariantBridges) from the symbols, so no back end has to re-derive it. A back end whose method identity includes the return type (the JVM's descriptor does) must make this operation reachable under each of them as well, or a call through the parent's type never reaches the override (N07, Contract 11 in EK9_BACKEND_IR_CONTRACTS.md). Empty when the operation overrides nothing or keeps every return type.

    • setBridgeReturnTypes

      public void setBridgeReturnTypes(List<String> bridgeReturnTypes)

    • getResolvedMethodName

      public String getResolvedMethodName()
      The resolved, arity-aware backend method name for this operation — the name a back-end MUST emit for the DEFINITION, and never re-derive from the operator glyph. Mirrors CallDetails.methodName on the call side so both planes agree. In particular the arity-overloaded operator - resolves to _negate when arg-less (unary negate) and _sub when arg-bearing (binary subtract) — the IR carries the correct name so the back-ends stop deducing (and stop mis-deducing arg-less - as _sub). Computed lazily from the symbol so the method's parameter list is always fully populated by read time. Non-operator methods return their plain name.
      Returns:
      the resolved runtime method name for this operation

    • getDebugInfo

      public DebugInfo getDebugInfo()

    • toString

      public String toString()
      Overrides:
      toString in class Object

    • accept

      public void accept(INodeVisitor visitor)
      Specified by:
      accept in interface INode

    • compareTo

      public int compareTo(OperationInstr o)
      Orders the operations of a construct in the emitted IR (via IRConstruct.getOperations()).

      The key is the FRIENDLY name, so the order is by return type, then method name, then the parameter list AS DISPLAYED - which includes the parameter NAMES. Renaming a parameter therefore re-orders that construct's OperationDfn blocks and churns its @IR/@BYTECODE goldens, even though nothing about the code changed (naming the two synthetic enum constructors 'other' and 'name' instead of 'arg' moved the String constructor ahead of the copy constructor, 2026-09-24). That is cosmetic churn, not a defect - but do not read this order as a signature order, and expect the goldens to move whenever a parameter is renamed.

      Specified by:
      compareTo in interface Comparable<OperationInstr>