Package org.ek9lang.compiler.symbols

Class SymbolTable

java.lang.Object
org.ek9lang.compiler.symbols.SymbolTable
All Implemented Interfaces:
Serializable, IScope
Direct Known Subclasses:
LocalScope, ModuleScope
public class SymbolTable extends Object implements IScope
We need to support simple things like classes which are unique per symbol table Or the fully qualified class names like 'com.some.A and com.other.A' so they won't collide. But we don't want to define constants/variables like 'int A and float A' this is a duplicate We do want method overloading like int A() and int A(String some param) But not int A() and float A() as that is not good. 
 So for the most part this is straight forward, but this issue is operators and type matching.
 i.e support for
 1. int A()
 2. int A(String v1)
 3. int A(String v1, int someItem)
 4. int A(int item, String other)
 5. int A(List of String list1)
 6. int A(List of Integer list2)
 7. float A(List of Integer list3, String other)
 8. int A(List of Double list4, String other)
 9. int A(SomeClass sc)
 10. int A(ClassThatExtendsSomeClass supersc)
When we define these we want them all to be defined and available in the appropriate scope. The issue is doing the resolve! We can't just say hey I'm trying to resolve 'A' that's just not enough We need to know: 
 1. Are we looking for a class(type), function/method or variable/constant in this context.
 2. What is it's name - in this case 'A'
 3. What type (or return type) are we expecting - but here we should accept a super class match
 with some weight match value
 4. What is the order and type of parameters - again we need to try and match with some weight
 using super class matches.
So what sort of algorithm can we use for this? 
 The Symbol has a type already when we define it - we know if it is an AggregateSymbol,
 MethodSymbol etc. We also know its name!
 We know the Symbol we will use for it's return type or what it is i.e the Symbol of Integer as
 the return type or what it is.
 For methods (which are Scoped Symbols) we also have the parameters (in order).
 So while parameters can be used when making the call this is just sugar - the order still has
 to match.

 Well we could have separate internal tables for methods/functions, classes/types and variables.
 So we can quickly and simply resolve obvious ones like variables and types.
 Then use more expensive operations for methods.

 Now for methods we can store in a hash map of method names - so in a simple case with just one
 method of name A we're done!
 But in that hashmap we store and List of all methods of that name - now we have the costly
 activity of going through each and getting the weight of each to find a match. in local scopes
 which ever is the best match we return - but clearly it is possible there is no match then we
 resort to moving back up the scope tree (as we do now).
See Also: