String reboot - (1a) incidental whitespace

[Brian Goetz]

To be clear: “closing delimiter influence” means that, before we strip off that blank line, we look at how much whitespace it has, and we include that in our calculation of “common leading whitespace prefix”.  (This has been called a “determining line” in prior discussions of alignment.). 

The degree of control goes in one direction only; you can use this to _decrease_ the amount of whitespace stripped by moving the closing delimiter to the left.  

I think we can assume that most of the time, users would prefer that the opening delimiter line up with the closing one, especially if we are essentially forcing them to put them on their own lines.  Saying

String s = “””
                   stuff
           “””;

feels more natural than

String s = “””
                   stuff
              “””;

or

String s = “””
                   stuff
       “””;

If we assume this to be the user’s default inclination, then “closing delimiter control” is, in this common case, also “opening delimiter control”; that the indentation from the opening quote is significant.  

That means that to get left-aligned strings under this approach, the user would have to do this:

String s = “””
           stuff
           more stuff
           “””;

or this

String s = “””
               stuff
               more stuff
               “””;

or this:

String s = “””
               stuff
               more stuff“””;  // no trailing NL

And to get indented strings, they would do:

String s = “””
               stuff
               more stuff
           “””;

So the tradeoff here is, as Jim suggests:

 - More control over indentation
 - Less ability to lean on an existing convention

Note that we seem to be leaning already towards using the position of the closing delimiter to determine whether there is a trailing NL or not.  I think going all the way with this is something users could get their heads around.  So it seems a reasonable option.  What do we think?



> On Apr 17, 2019, at 9:13 AM, Jim Laskey <james.laskey at oracle.com> wrote:
> 
> Brian points out that we under highlighted "closing delimiter influence".  Liam eludes to it in his discussion, but I'll break the discussion out here.
> 
> In the following example I'll use "." to indicate whitespace;
> 
> String s = """
> ...............line 1
> ...................line 2
> ...........""";
> 
> The outcome without closing delimiter influence;
> 
> line 1
> ....line 2
> 
> represents the result of only including line 1 and line 2 in the determination of the amount of whitespace needs to be removed.
> 
> 
> The outcome with closing delimiter influence;
> 
> ....line 1
> ........line 2
> 
> represents the result including line 1, line 2 AND the line containing the closing delimiter.
> 
> The negative aspect of the including the closing delimiter line is that the fat delimiter pattern would have to deviate from the brace pattern.
> 
> Cheers,
> 
> -- Jim
> 
> 
>> On Apr 17, 2019, at 9:55 AM, Jim Laskey <james.laskey at oracle.com <mailto:james.laskey at oracle.com>> wrote:
>> 
>> To paraphrase McLuhan, I think that we need to keep the focus on the rider and not the horse they rode in on.  This was the main reason I pushed for backtick over triple double quote; making it about the content and not the syntax around it.
>> 
>> In the Raw String Literal round, I suggested that
>> 
>> String query = ```````````````````````````````````````````````
>>                SELECT `EMP_ID`, `LAST_NAME` FROM `EMPLOYEE_TB`
>>                WHERE `CITY` = ‘INDIANAPOLIS'
>>                ORDER BY `EMP_ID`, `LAST_NAME`;
>>                ```````````````````````````````````````````````;
>> 
>> might freak out some developers.
>> 
>> If you break this example down, the multiple quotes are not really for the language, but instead for the eye of the beholder. Alignment wise, all the language cares about is the first character of each of the delimiters. The last character can be derived from the longest line based on end of line.  So this reduces down to 
>> 
>> String query = ``
>>                SELECT `EMP_ID`, `LAST_NAME` FROM `EMPLOYEE_TB`
>>                WHERE `CITY` = ‘INDIANAPOLIS'
>>                ORDER BY `EMP_ID`, `LAST_NAME`;
>>                ``; // need `` because of the enclosed backticks
>> 
>> or in the fat delimiter world 
>> 
>> String query = """
>>                SELECT `EMP_ID`, `LAST_NAME` FROM `EMPLOYEE_TB`
>>                WHERE `CITY` = ‘INDIANAPOLIS'
>>                ORDER BY `EMP_ID`, `LAST_NAME`;
>>                """;
>> 
>> In the incidental whitespace discussion, this aligns with closing delimiter influencing indentation.  Brian and I have been of four minds on this, where I tend to favour closing delimiter influence and Brian tends otherwise. My strongest argument thus far has been, "Swift does it."
>> 
>> As you point out, management of literal boxing is nightmarish and heavily reliant on IDE support, and I feel strongly that is a problem.  I'm in and out of BBEdit , VSC, Atom, and Coda as much as I am in Intellij.  The IDE answer doesn't work for me, and may not for (many?) others.  What I do see is an IDE putting a light gray box or a different background colour to highlight the "auto aligned" string content.
>> 
>> Bottom line, closing delimiter influencing indentation provides the same information as boxing with less hassle.
>> 
>> Cheers,
>> 
>> -- Jim
>> 
>> 
>> 
>>> On Apr 16, 2019, at 5:14 PM, Guy Steele <guy.steele at oracle.com <mailto:guy.steele at oracle.com>> wrote:
>>> 
>>> 
>>>> On Apr 16, 2019, at 4:02 PM, Brian Goetz <brian.goetz at oracle.com <mailto:brian.goetz at oracle.com>> wrote:
>>>> 
>>>> Indeed, it does solve a number of "figure out what was the user thinking" questions.  
>>>> 
>>>> You hit the nail on the head regarding IDE support.  Our original thinking was that it should be easy to cut and paste between a (say) JSON document and a Java source program, without having to mangle it up in an annoying and error-prone way.
>>>> 
>>>> I think what you're saying is, in the age of IDEs, that this is not such a problem, and we should focus on what yields the most _readable_ code, on the theory that writing is the job of the IDE?
>>> 
>>> Yes, exactly.  Though, as I pointed out in my subsequent message, it’s easy to give the programmer a choice between a quick-and-easy way to cut-and-paste that is easy to write, and a more labor-intensive or IDE-intensive version that may be easier to read (at least in some situations).
>>> 
>>> At least we should explore such options.
>>> 
>>> —Guy
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190417/be075ec0/attachment-0001.html>