Class CallSymbol

java.lang.Object
org.ek9lang.compiler.symbols.Symbol
org.ek9lang.compiler.symbols.ScopedSymbol
org.ek9lang.compiler.symbols.MethodSymbol
org.ek9lang.compiler.symbols.CallSymbol
All Implemented Interfaces:
Serializable, IMayReturnSymbol, IScope, IScopedSymbol, ISymbol, ISymbolNature, ITokenReference
public class CallSymbol extends MethodSymbol
Just re-uses the bulk of method symbol for when we want to make a symbol that is a call to an actual method. This will be used to build up the sort of call we want to make based on the source . We then have to resolve this CallSymbol against a real method symbol.
See Also:

  • Constructor Details

    • CallSymbol

      public CallSymbol(String name, IScope enclosingScope)

  • Method Details

    • isFormOfDeclarationCall

      public boolean isFormOfDeclarationCall()

    • setFormOfDeclarationCall

      public void setFormOfDeclarationCall(boolean formOfDeclarationCall)

    • clone

      public CallSymbol clone(IScope withParentAsAppropriate)
      Description copied from interface: ISymbol
      Clone the symbol and re-parent if this symbol like a method should have a parent. Other symbols like VariableSymbols are un-parented
      Specified by:
      clone in interface IScope
      Specified by:
      clone in interface IScopedSymbol
      Specified by:
      clone in interface ISymbol
      Overrides:
      clone in class MethodSymbol

    • cloneIntoCallSymbol

      protected CallSymbol cloneIntoCallSymbol(CallSymbol newCopy)

    • getResolvedSymbolToCall

      public ScopedSymbol getResolvedSymbolToCall()

    • setResolvedSymbolToCall

      public void setResolvedSymbolToCall(ScopedSymbol symbol)
      Set the actual method/function that should be called.

    • isReturningSymbolPresent

      public boolean isReturningSymbolPresent()
      Description copied from class: MethodSymbol
      Some methods have a named return symbol 'like rtn as String' for example. In other cases a method will not return anything (We use 'Void') in the case as the 'type'. So when a Returning Symbol is set we use the type of the returning variable as the type return on the method.
      Specified by:
      isReturningSymbolPresent in interface IMayReturnSymbol
      Overrides:
      isReturningSymbolPresent in class MethodSymbol

    • getReturningSymbol

      public VariableSymbol getReturningSymbol()
      Description copied from class: MethodSymbol
      Provide a symbol that is returned from this method. Note in EK9 this is not just a type but actually a variable symbol (that has a type).
      Specified by:
      getReturningSymbol in interface IMayReturnSymbol
      Overrides:
      getReturningSymbol in class MethodSymbol

    • getFriendlyScopeName

      public String getFriendlyScopeName()
      Description copied from interface: IScope
      Useful for printing out errors and information. The scope name might be a complex generated name used internally a bit like symbol names are. So some items are both scopes and symbols - so ideally we'd want to use a friendly name where possible.
      Specified by:
      getFriendlyScopeName in interface IScope
      Overrides:
      getFriendlyScopeName in class ScopedSymbol
      Returns:
      The friendly name to be used for the developer.

    • getFriendlyName

      public String getFriendlyName()
      Description copied from interface: ISymbol
      Provide the name an end user would need to see on the screen. Normally this is just 'getName' but in the case of Templates We use a very nasty internal naming for List of SomeClass - which will probably be something like _List_hashed_version_of_ComeClass and the end user needs to see 'List of SomeClass' for it to be meaningful.
      Specified by:
      getFriendlyName in interface ISymbol
      Overrides:
      getFriendlyName in class MethodSymbol
      Returns:
      a user presentable of the symbol name.

    • equals

      public boolean equals(Object o)
      Description copied from class: Symbol
      Two symbols are the same symbol when they agree on name, category, genus, mutability AND the declaration site they came from.

      The source token is part of identity deliberately. Name alone is not enough: symbol names are unqualified here, so two unrelated variables both called count, or two types called Foo in different modules, would otherwise compare equal. The compiler relies on telling those apart - CodeFlowMap keys initialisation state on Map<IScope, Map<ISymbol, SymbolAccess>>, and conflating two same-named declarations there makes flow analysis attribute one variable's initialisation to another.

      That distinction used to be present ONLY in Symbol.hashCode(), which is why this looked like it worked: two same-named symbols compared equal yet hashed apart, so hash collections usually - but not reliably - kept them separate, while any direct equals call saw them as one. Encoding it here makes the two agree. See SymbolEqualsHashCodeContractTest.

      Overrides:
      equals in class MethodSymbol

    • hashCode

      public int hashCode()
      Description copied from class: Symbol
      Mixes in exactly the fields Symbol.equals(Object) compares, and nothing else.

      A hashCode may legitimately use FEWER fields than equals (that only causes collisions, which are correct), but never MORE: any extra field makes two symbols that compare equal land in different buckets, so a HashSet silently holds visible duplicates and a HashMap lookup misses an entry that is present. This method used to mix in purity, which no equals at THIS level consults - purity belongs in FunctionSymbol, the level whose equals compares it. The source token stays, and is now matched by Symbol.equals(Object). See SymbolEqualsHashCodeContractTest.

      Overrides:
      hashCode in class MethodSymbol