Class CaptureScopedSymbol

All Implemented Interfaces:
Serializable, ICanCaptureVariables, IScope, IScopedSymbol, ISymbol, ISymbolNature, ITokenReference
Direct Known Subclasses:
PossibleGenericSymbol

public class CaptureScopedSymbol extends ScopedSymbol implements ICanCaptureVariables
Just focuses on the ability to possible capture variables from an enclosing scope. This is primarily used for dynamic functions and classes.
See Also:
  • Constructor Details

    • CaptureScopedSymbol

      public CaptureScopedSymbol(String name, Optional<ISymbol> type, IScope enclosingScope)
    • CaptureScopedSymbol

      public CaptureScopedSymbol(String name, IScope enclosingScope)
  • Method Details

    • clone

      public ScopedSymbol 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 ScopedSymbol
    • cloneIntoCaptureScopedSymbol

      protected CaptureScopedSymbol cloneIntoCaptureScopedSymbol(CaptureScopedSymbol newCopy)
    • getModuleScope

      public IScope getModuleScope()
    • setModuleScope

      public void setModuleScope(IScope moduleScope)
    • isMarkedAbstract

      public boolean isMarkedAbstract()
      Specified by:
      isMarkedAbstract in interface ISymbol
    • setMarkedAbstract

      public void setMarkedAbstract(boolean markedAbstract)
    • getCapturedVariables

      public Optional<CaptureScope> getCapturedVariables()
      Description copied from interface: ICanCaptureVariables
      Make the scope that holds the captured variables (if any accessible).
      Specified by:
      getCapturedVariables in interface ICanCaptureVariables
      Returns:
      The scope holding the captured variables.
    • setCapturedVariables

      public void setCapturedVariables(CaptureScope capturedVariables)
      It is possible to capture variables in the current scope and pull them into the function, so they can be used.
      Specified by:
      setCapturedVariables in interface ICanCaptureVariables
      Parameters:
      capturedVariables - The variables to capture.
    • setCapturedVariables

      public void setCapturedVariables(Optional<CaptureScope> capturedVariables)
    • setCapturedVariablesVisibility

      public void setCapturedVariablesVisibility(boolean isPublic)
      The variables that have been captured can be given public access if needed.
    • getPrivateVariablesForDisplay

      protected String getPrivateVariablesForDisplay()
    • resolveExcludingCapturedVariables

      public Optional<ISymbol> resolveExcludingCapturedVariables(SymbolSearch search)
      Description copied from interface: ICanCaptureVariables
      Try and resolve a symbol but exclude looking in captured variables.
      Specified by:
      resolveExcludingCapturedVariables in interface ICanCaptureVariables
    • resolveInThisScopeOnly

      public Optional<ISymbol> resolveInThisScopeOnly(SymbolSearch search)
      Description copied from interface: IScope
      Just look in own scope.
      Specified by:
      resolveInThisScopeOnly in interface IScope
      Overrides:
      resolveInThisScopeOnly in class ScopedSymbol
    • 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 ScopedSymbol
    • 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 ScopedSymbol