Initial and partial high-level REPL API review

[Robert Field]

Note: consistent with this division,

        JShell.drop(PersistentSnippet snippet)

-Robert

On 07/15/15 11:40, Robert Field wrote:
> 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
>