Initial and partial high-level REPL API review

[Paul Sandoz]

On Jul 15, 2015, at 8:40 PM, Robert Field <robert.field at oracle.com> 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?
> 

I like the move to Snippet and the state of being overwritten (or more generally redefined?) (not an easy refactor), it better maps to transitioning, it's easy to obtain the old and new source via the associated event, and drop the old to reap the memory in JShell but still retain the immutable state e.g. history.

Should there be a method on a Snippet to obtain it's associated JShell?

If so it would be trivial to add query methods deferring to JShell i.e. as a user of the API do we really need to care about the distinction between immutable state and queries if we clear demarcate such methods as queries on the associated JShell?

For example if i have a VariableDeclSnippet i kind of intuitively know it's a named "box" for a value and that it has to be active (and the shell) for me to obtain that value.

I would give things more of a test drive but i am getting a build error:

Compiling files for jdk.jline
javac: file not found: /Users/sandoz/Projects/jdk9/kulla-dev/build/macosx-x86_64-normal-server-release/jdk/modules/jdk.jline/_the.jdk.jline_batch.tmp (No such file or directory)
make[3]: *** [/Users/sandoz/Projects/jdk9/kulla-dev/build/macosx-x86_64-normal-server-release/jdk/modules/jdk.jline/_the.jdk.jline_batch] Error 3
make[2]: *** [jdk.jline-java] Error 2

Paul.