Kulla: JShell API ready for round two review

[Maurizio Cimadamore]

On 10/08/15 18:26, Robert Field wrote:
> There are a lot of ways one could slice the state, but having a single 
> enum that represents the state seems most simple to me.  What do 
> others think?
>
> The active-ness is a query on the Status (tracksupdates) as is its 
> visibility (isDefined).
>
> A SUCCESS dimension doesn't make sense for many of the Status states.
>
> EXPLICIT/IMPLICIT is not part of the Status, that is part of the 
> transition and is encoded in the event.
I think we are mostly saying the same things - in my mind, the state is 
just one of:

NON_EXISTENT
EXECUTABLE
VISIBLE
UPDATEABLE
INACTIVE

Where EXECUTABLE (can execute, is visible, can receive updates) > 
VISIBLE (is visible, can receive updates) > UPDATEABLE (can receive updates)



You start from NON_EXISTENT - the initial (blank) state; then you 
transition to either EXECUTABLE (success), VISIBLE (recoverable failure) 
or INACTIVE (unrecoverable failure) upon explicit compilation.

Once in EXECUTABLE/VISIBLE/UPDATEABLE, you can again transition to 
EXECUTABLE, VISIBLE, UPDATEABLE upon implicit compilation, as before 
(where UPDATEABLE is only reached in cases of signature errors).

Finally, there's an extra arrow from EXECUTABLE/VISIBLE/UPTADEABLE to 
INACTIVE for handling 'drop'.

I think what I'm trying to say is that the current status enum seems to 
capture not only the states, but also the transitions that led to that 
given state - and that's the bit that I don't get; if an expression is 
not active w.r.t. updates/visibility, does it matter if it's that way 
because an unrecoverable error, or because it has been explicitly 
dropped or because it has been overwritten?


Maurizio
>
> Thanks,
> Robert
>
> On 08/10/15 07:59, Maurizio Cimadamore wrote:
>>
>>
>> On 10/08/15 15:43, Maurizio Cimadamore wrote:
>>> Of course, now all three of those are needed, as the state is all 
>>> folded together; but with a richer state representation, I can 
>>> easily see (3) going down to only 3 slots (NON_EXISTENT, ACTIVE, 
>>> INACTIVE) 
>> And, by folding 4 with 1, I think only three axis are needed:
>>
>> 1) Last compilation result kind
>>     SUCCESS
>>     CORRALLED
>>     FAILED
>>
>> 2) Last compilation kind
>>     EXPLICIT
>>     IMPLICIT
>>
>> 3) Snippet state
>>    NON_EXISTENT
>>    ACTIVE
>>    INACTIVE
>>
>> Note that the snippet state is really (3) - I believe (1) and (2) 
>> together are an optional extra info associated with the snippet 
>> status (only when the snippet is ACTIVE).
>>
>> This would lead to something like this:
>>
>> class Status {
>>     enum Kind {
>>        NON_EXISTENT,
>>        ACTIVE,
>>        INACTIVE
>>     }
>>
>>     Optional<CompilationStatus> compilationStatus;
>> }
>>
>> class CompilationStatus {
>>    enum Kind {
>>        IMPLICIT,
>>        EXPLICIT;
>>    }
>>
>>    enum Result {
>>        SUCCESS,
>>        CORRRALLED,
>>        FAILED;
>>    }
>>
>>    Kind kind; Result result;
>> }
>>
>> Maurizio
>