String reboot - (1a) incidental whitespace

[Jim Laskey]

The positive aspect; having control of indentation at the literal level.

> On Apr 17, 2019, at 10: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/f708ca07/attachment.html>