UI review: Key.id() was: jshell commands

[Robert Field]

I think some background is missing in this conversation.  

Currently:

(1) id() is the unique numeric identifier of a Key.
(2) Every snippet has a Key, including failed snippets, dropped snippets, and overwritten snippets.
(3) The Key of a variable or class snippet is its name, the Key of a method is its name and parameter types.
(4) If a snippet is entered with the same Key as a previous snippet, the Key is the same, the associated snippet for that Key changes.
All the above are API level.  The API doesn’t know anything about start-up files or list filtering. Or commands for that matter.

(5) /list, by default, shows interactively entered active (not failed, dropped, or withdrawn) snippets in id() order.
(6) That means, even if there are no start-up entries (-nostartup), /list won’t necessarily start with “1” since your first entries may have failed.
(7) The last entered snippet might not be the last listed in /list if it has the same Key of a previously entered snippet.
(8) /list all — shows snippets from the start-up, from /open, it shows failed, dropped, and withdrawn snippets.

Exercise for the reader: Apply your proposed id() schemes to --

Start-up:

	int x = 5;

Interactive:

	snurble snurble;
	int y = 3;
	int x = y * y;
	/list

-Robert


> On Jul 1, 2015, at 9:37 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:
> 
> 
> On Jun 30, 2015, at 2:02 AM, Brian Goetz <brian.goetz at Oracle.COM> wrote:
> 
>> Now that you have whacked us over the head with "hey, you guys are looking in the wrong direction", I tend to agree.  In fact, that the elements of /list show up starting with 9 is also weird.
>> 
> 
> Yes, and it's not constant.
> 
> 
>> So, how about reflecting this more directly; have the "startup IDs" start at something like auto.1 or startup.1, and then flip over to 1 when we finish with startup.  Then /list would start with 1; /list all would look like:
>> 
>> auto.1: import ...
>> auto.2: import
>> 1: 1 + 1
>> 
> 
> I like that approach.
> 
> Paul.
> 
>> The only important reason that we even need an ID for the startup entries is so we can /drop it.  Having an ID of the form "auto.1" works fine for that.  There's no reason ID has to be an int, is there?
>> 
>>> Otherwise, the intermediate results of the startup file should be
>>> dropped.  Or at least they should not interfere with the auto-generated
>>> names for interactive results.
>>> 
>>> Two compromises possible on that:
>>> 
>>> 1. If for some reason we must, auto-generate a different set of names
>>> for the startup file, starting with $_ (think, "negative") or $0:
>>> 
>>> 1+1;
>>> $1 = 2;
>>> $_1;  // host id from startup, etc.
>>> 
>>> 2. If you buy my argument that auto-generated things are usually
>>> useless, have an opt-in argument for those special times when you need
>>> auto-numbering of the file.  Replaying a previous interactive input is
>>> really a different use case from reusing a common profile.
>>> 
>>> Such a special time would be replaying scripts, but I can't think of any
>>> other.  Perhaps that is envisioned as the default.  In that case, we
>>> should be sure that it in the *other default*, when pulling from a
>>> startup file like ~/.kullarc, it should be easy to suppress the creation
>>> of $N variables.
>>> 
>>> — John
>