Kulla: JShell API ready for round two review

[Maurizio Cimadamore]

On 12/08/15 00:44, Robert Field wrote:
> OK, now I get what you are saying, those five states, or four if you collapse NON_EXISTENT into INACTIVE, plus a how-did-it-get-that-way (which could be associated with the transition, and thus could be in the event) would separate functional state from historic information.
Yes! To me these are two rather orthogonal aspects, and, as you mention, 
it is not unreasonable to imagine a system that would keep track of all 
the transitions associated with a given snipped during its life cycle; 
if everything is flattened into 'states', you lose historical 
information, but you gain in simplicity.
>
> To your “does it matter” question: rephrased, does it matter to the API user (tool developer) or the end user?  I don’t think it matters directly to the API user; Really, aside from how the information is presented to the end-user, the API user doesn’t care about Status at all.  However, I think it does to the end user. How it matters to the end user: (1) if/when giving feedback about what has occurred, you would want “dropped” or “overwritten” vs “became inactive”, but that rightly goes with the transition edge (event), (2) when displaying all snippets (including inactive ones, e.g.. “/list all") I plan to display (in some way) the Status (in the current sense), where, again, it would be quite clarifying for the end-user to distinguish “overwritten” from “rejected” from “dropped”.  In this case the “why" is persistently interesting.  It is true, the current Status enum could be decomposed into what and why enums, and if the why is in the event, the tool could cache it. There is more conceptual purity, but use and API are more complex.
>
> The how-did-it-get-that-way edges would be:
> 	Added
> 	Updated (per dependency)
> 	Overwritten
> 	Dropped
>
> Where, for example, INACTIVE X Added and INACTIVE X Updated would be “rejected”.
>
> An intermediate point would be to have nested decomposition (names are placeholders only):
>
> 	Liveness:
> 		ALIVE
> 		CORRALLED
> 		RESUSITATABLE
> 		DEAD
>
> 	Status:
> 		ACTIVE(ALIVE)
> 		ACTIVE_CORRALLED(CORRALLED)
> 		ACTIVE_FAILED(RESUSITATABLE)
> 		DROPPED(DEAD)
> 		NONEXISTENT(DEAD)
> 		OVERWRITTEN(DEAD)
> 		REJECTED_FAILED(DEAD)
>
> Or, we could keep it simple with the current Status.
Yeah - it's mostly an usability trade-off; my guts tell me that the two 
sensible choices are (i) keeping it simple (as you did with current 
state-enum) or (ii) strive for purity by separating events from states, 
as that would enable more use cases. I think a compromise will never be 
as powerful as (ii) and will likely be significantly more cumbersome to 
use than (i). My 0.02$.

Maurizio
>
> -Robert
>
> 		
>
>> On Aug 11, 2015, at 3:09 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
>>
>>
>>
>> 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