Class TypeNameOrException

java.lang.Object
org.ek9lang.compiler.common.TypeNameOrException
All Implemented Interfaces:
Function<ISymbol,String>
public final class TypeNameOrException extends Object implements Function<ISymbol,String>
Extracts the fully qualified type name from the symbol. Or throws an Exception if the symbol is un-typed. Missing types should have been detected in earlier stages. So be carful which phase you use this with.

Optionally accepts a type resolver function for Scenario 3 parameterized type IR generation, where type parameter FQNs (e.g., "Module::Renderer::T") need to be substituted with concrete type FQNs (e.g., "org.ek9.lang::Integer").

  • Constructor Details

    • TypeNameOrException

      public TypeNameOrException()
      Create with identity resolver (no type substitution).

    • TypeNameOrException

      public TypeNameOrException(Function<ISymbol,String> typeResolver)
      Create with a type resolver for Scenario 3 type parameter substitution.

      The resolver takes the type SYMBOL, not its name: a parameterised type's FQN is a one-way digest, so a nested parameterisation (List of T) can only be re-pointed at its concrete counterpart structurally, from the symbol's type arguments. See IRGenerationContext#resolveTypeName(ISymbol).

      Parameters:
      typeResolver - Function that maps a type symbol to the concrete type FQN to emit

  • Method Details

    • apply

      public String apply(ISymbol symbol)
      Specified by:
      apply in interface Function<ISymbol,String>

    • typeSymbolOf

      public ISymbol typeSymbolOf(ISymbol symbol)
      THE type SYMBOL whose fully qualified name apply(ISymbol) emits - deliberately the same returning-symbol rule, yielding the symbol rather than its name.

      Use this when a site both prints a type via apply(ISymbol) and needs to read that same type (resolve a member on it, extract call metadata from the resolved callee). Mirroring apply is the whole point: the two answers cannot then describe different types. Re-deriving the rule inline as symbolTypeOrException.apply(symbol) silently disagrees with the emitted name for any IMayReturnSymbol that has a returning symbol - so the CALL would name one type and carry another type's metadata.

      This is not a general "give me the receiver type" helper. For an IMayReturnSymbol it yields the RETURN type - right for a call expression (foo()? tests the returned value), wrong if a bare function symbol is ever handed in as a call receiver. Where that matters, fix the caller's choice of apply; do not silently diverge here.