Class StreamCallSymbol

java.lang.Object
org.ek9lang.compiler.symbols.Symbol
org.ek9lang.compiler.symbols.ScopedSymbol
org.ek9lang.compiler.symbols.MethodSymbol
org.ek9lang.compiler.symbols.StreamCallSymbol
All Implemented Interfaces:
Serializable, IMayReturnSymbol, IScope, IScopedSymbol, ISymbol, ISymbolNature, ITokenReference
public class StreamCallSymbol extends MethodSymbol
Just re-uses the bulk of method symbol. This is only used in part of the stream pipeline. We need additional information surrounding the type that can be accepted and the type that is produced (chained). In some cases (like a call to head) we can accept anything in and will produce the same back out. But a filter can only accept a certain type in - but will then also product that same type out. A map on the other hand will only accept a certain type and will product another type (maybe - depending on the map). Flatten can only accept something is can iterate over and will then product whatever that type is that is provided by the iterator. This is the 'glue' between streaming commands and functions.
See Also:

  • Constructor Details

    • StreamCallSymbol

      public StreamCallSymbol(String name, IScope enclosingScope)

  • Method Details

    • clone

      public StreamCallSymbol 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

    • cloneIntoStreamCallSymbol

      protected StreamCallSymbol cloneIntoStreamCallSymbol(StreamCallSymbol newCopy)

    • getResolvedPipeMethod

      public MethodSymbol getResolvedPipeMethod()

    • setResolvedPipeMethod

      public void setResolvedPipeMethod(MethodSymbol resolvedPipeMethod)

    • isConsumesSymbolPromotionRequired

      public boolean isConsumesSymbolPromotionRequired()

    • setConsumesSymbolPromotionRequired

      public void setConsumesSymbolPromotionRequired(boolean consumesSymbolPromotionRequired)

    • isSinkInNature

      public boolean isSinkInNature()

    • setSinkInNature

      public void setSinkInNature(boolean sinkInNature)

    • isCapableOfConsumingAnything

      public boolean isCapableOfConsumingAnything()

    • setCapableOfConsumingAnything

      public void setCapableOfConsumingAnything(boolean capableOfConsumingAnything)

    • setProducerSymbolTypeSameAsConsumerSymbolType

      public void setProducerSymbolTypeSameAsConsumerSymbolType(boolean producerSymbolTypeSameAsConsumerSymbolType)

    • isDerivesProducesTypeFromConsumesType

      public boolean isDerivesProducesTypeFromConsumesType()

    • setDerivesProducesTypeFromConsumesType

      public void setDerivesProducesTypeFromConsumesType(boolean derivesProducesTypeFromConsumesType)

    • isProducesTypeMustBeAFunction

      public boolean isProducesTypeMustBeAFunction()

    • setProducesTypeMustBeAFunction

      public void setProducesTypeMustBeAFunction(boolean producesTypeMustBeAFunction)

    • getConsumesSymbolType

      public ISymbol getConsumesSymbolType()

    • setConsumesSymbolType

      public void setConsumesSymbolType(ISymbol consumesSymbolType)
      This sets the type of symbol that stream can consume.

    • getProducesSymbolType

      public ISymbol getProducesSymbolType()

    • setProducesSymbolType

      public void setProducesSymbolType(ISymbol producesSymbolType)
      This sets the type of symbol that stream can produce.

    • 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