Class OperatorTargetMethodResolver

java.lang.Object

org.ek9lang.compiler.phase7.calls.OperatorTargetMethodResolver

public final class OperatorTargetMethodResolver
extends Object

THE shared "resolve the callee method on its target type" step for phase-7 synthesised call sites. Use this - do not re-derive a variant. It carries two pieces of hard-won knowledge that an inline aggregate.resolveMember(new MethodSymbolSearch(name)) silently gets wrong (see the dual-glyph note below), and every phase-7 site that needs a resolved callee - whether to read its defining type or to read its CallMetaDataDetails - must go through here.

Uses resolveMember with the argument types so SymbolMatcher finds the correct overload - including coercible (promotable) matches, e.g. Float._addAss(Float) for f += celsius where Celsius promotes to Float. The symbol table keys operator methods by EK9 name (":=:"), so the JVM method name ("_copy") is reverse-mapped for the search. A non-operator method name (e.g. iterator, hasNext) is searched as given.

Negate is dual-glyph. The JVM method _negate is aliased by TWO EK9 operators: ~ (declared by Boolean/Bits/List/Colour as operator ~) and the zero-arg unary - (declared by the numeric types as operator -, split from binary _sub by arity in phase 2's ValidOperatorOrError.minusOperatorOrError). OperatorMap.getBackward("_negate") only yields ~ (the - key is taken by binary _sub), so a ~ search misses on a numeric type whose negate is stored under -. This mirrors, in reverse, the one-way -/not -> ~ normalisation that UnaryOperationGenerator does on the way in: on a ~ miss for a zero-arg call, retry the unary -. A zero-parameter search matches ONLY the unary - (SymbolMatcher rejects arity mismatch), never binary _sub. Without this the dispatch/defining type silently falls back to the static receiver - correct for the on-receiver common case, but a wrong, never-emitted symbol for an INHERITED numeric negate on the eagerly-linked native back-end (the cea4d156c defining-type remedy otherwise no-ops here).

See Also:

• the metadata-facing facade most synthesised sites want

Constructor Summary

Constructors

Constructor	Description
OperatorTargetMethodResolver()

Method Summary

Modifier and Type	Method	Description
Optional<ScopedSymbol>	apply(ISymbol targetType, String methodName, List<ISymbol> argumentTypes)	Resolve a method/operator on the target type, returning the resolved symbol itself (not just type names), so callers can read its defining type, return type and metadata rather than re-deriving them.

Methods inherited from class Object

clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Details

OperatorTargetMethodResolver

public OperatorTargetMethodResolver()

Method Details

apply

public Optional<ScopedSymbol> apply(ISymbol targetType,
 String methodName,
 List<ISymbol> argumentTypes)

Resolve a method/operator on the target type, returning the resolved symbol itself (not just type names), so callers can read its defining type, return type and metadata rather than re-deriving them.

Parameters:

targetType - the type the call is made ON (a non-aggregate never resolves)

methodName - the JVM method name (_copy) or the EK9 name (:=:) or a plain method name (iterator)

argumentTypes - the resolved argument types, driving overload selection

Returns:

the resolved method, or empty when the target is not an aggregate or declares no such member