Initial and partial high-level REPL API review

[Robert Field]

Paul,

On 06/30/15 09:45, Paul Sandoz wrote:
> Particular code snippets can have methods associated with the operations, for example:
>
>    - All code snippets would have the source, status, diagnostics and subKind operations
>    - The variable declaration code snippet would have the varValue operation
>
> It would then be marginally easier to operate on snippets in bulk, rather than having to go back to corresponding JShell instance. For example, then one could do:
>
>    JShell js = ..
>
>    Stream< VariableDeclKey > variables = js.keys().stream()
>        .filter(k -> k.status().tracksUpdates)
>        .filter(k -> k.kind() == Key.Kind.VARIABLE)
>        .map(k -> (VariableDeclKey)k);
>
> with no need to refer or capture "js". The stream is entirely self-contained.

With the move to the API being source-snippet-based, these have moved 
from being on JShell to being on Snippet:

     source()
     subKind()
     signature()          -- (DeclationSnippet)

while still leaving all accessors on Snippet immutable.

This leaves the following still on JShell:

     status(Snippet)
     unresolved(DeclarationSnippet)
     diagnostics(Snippet)
     varValue(VariableDeclSnippet)

these are all mutable and a function of the cross product of the source 
Snippet with the current state of the JShell.  They are also dependent 
on the overall state of the JShell (has it been closed?), and thus 
should throw state closed exceptions (some more obviously than others). 
It thus seems appropriate that they reside on JShell.

Make sense?

Thanks,
Robert