Kulla API changes

[Brian Goetz]

This looks good to me.  Minimal and type-safe.  

Minor typo: valValue -> varValue.  

There’s a second set of questions lined up behind this one, that of sync-vs-async interaction between the REPL client and the REPL API.  Right now, the “updates” part of the eval result is really a bag of events delivered synchronously.  We should consider just making them events to which a client can subscribe.  Similarly, other events we might want to support are {var,method,class}-created, varValueChanged, etc.  

Separately, I like the idea of going one level deeper on class members.  If we give fields/methods of top-level classes a Key also, then we can add:

    List<VarKey> classFields(classKey)
    List<MethodKey> classMethods(classKey)

to EvalState so we can introspect over the members of top-level classes.  (The primary value of this is to facilitate more granular testing of class redefinition scenarios.)  

On Apr 15, 2015, at 11:12 PM, Robert Field <robert.field at oracle.com> wrote:

> I have completed the analysis of information access structure in the Kulla API.
> The synopsis is that the two stable points with the least complexity are the original Snippet/Info design and Key based design with queries on EvalState and no Info structure (the later, as you predicted, Brian).
> Since the original design did not as completely separate out the the various levels of dynamism and had flat queries with sometimes null results, I plan to move to the Key based design.
> 
> Note: because the tests are currently centered on Snippet/Info, I will be making the change in a step-wise manner to optimize for stability.
> 
> I'm starting the overhaul now, so feedback early will save cycling.
> 
> Here is a sketch of the new API (new/changed stuff in bold, removed in strike-through, interfaces/classes/enums in italics) --
> 
> EvalState:
>   eval(String)
>   valValue(VarKey)
>   currentResolution(DeclarationKey)
>   addToClasspath(String)
>   close()
>   variables() => List<VarKey>
>   methods() => List<MethodKey>
>   classes() => List<ClassKey>
>   keys() => List<Key>
>   registerOnStateShutdown()
>   source(key)
>   kind(key)
>   signature(DeclarationKey)
> 
> Key:
>   id()
>   category()  => Category
>   DeclarationKey:
>     name()
>     ClassKey
>     VarKey
>     MethodKey:
>       parameterTypes() => String
>   ImportKey:
>     name()
>     isStatic()
>   UniqueKey  // no other input will get the same key
>     StatementKey
>     ExpressionKey:
>       name()            // note: these are validly part of the key only because each key is unique
>       typeName()    // "" ""
> 
> EvalResult:
>   outcome
>   diagnostics
>   info
>   key => Key
>   updates
>   exception
>   value
> 
> SnippetInfo:  // all removed, methods not listed
>   DeclarationInfo
>     ClassInfo
>     MethodInfo
>     VarInfo
>   ImportInfo
>   ExpressionInfo
>   StatementInfo
> 
> Kind:
>   ... // unchanged, but moved out of the deleted SnippetInfo
> 
> Category: // one-to-one with Key concrete classes
>   enum -- ImportSnippet, ClassSnippet, MethodSnippet, VariableSnippet, ExpressionSnippet, StatementSnippet
> 
> ResolutionStatus:
>   ... // unchanged
> 
> 
> Comments???
> 
> -Robert
>