Comment received on amber-spec-comments

I should mention up front that text blocks are a preview feature and this open discussion is important before we lock the feature down. Unlike the multi-faceted raw string literals, text blocks attempt to do one thing well; provide a literal that makes it easy to express multiple lines of text. Hence, developers should really be thinking of text blocks as being more like the content of a text file and less like a string literal. That is, ideal for streaming and maybe less so for string manipulation. To counter the suggested examples, here is a reasonable example where that final line terminator works well; String part1 = """ Mary had a little lamb Whose fleece was white as snow. """; String part2 = """ And, everywhere that Mary went The lamb was sure to go. """; String verse = part1 + part2; The result is exactly what one would intuitively expect; Mary had a little lamb␊ Whose fleece was white as snow.␊ And, everywhere that Mary went␊ The lamb was sure to go.␊ Let's look at the origin of the final line terminator in detail. Take the following example, noting the location of the line terminators (␊); String x = """ Mary had a little lamb␊ Whose fleece was white as snow.␊ """; The closing delimiter is preceded by the line terminator on the prior line. Since the line terminator is not part of closing delimiter, this final line terminator is actually part of the string content. The result here is "Mary had a little lamb␊Whose fleece was white as snow.␊". The lines all end with line terminators. Let's try a new example where we move the closing delimiter up to the prior line; String y = """ Mary had a little lamb␊ Whose fleece was white as snow."""; In this case, the closing delimiter is preceded by the ".". Thus, the result in this case is "Mary had a little lamb␊Whose fleece was white as snow.". The lines are all joined with line terminators. Once you take this on mentally, it's easy to apply. Further, if the compiler were to strip away that final line terminator in the first case, there would be no way to distinguish the origins of x and y. This minimizing the loss of information is also an important part of extending text block design. This all said, text blocks were carefully designed to be the foundation for further string literal evolution. In a upcoming proposal (https://bugs.openjdk.java.net/browse/JDK-8227870 <https://bugs.openjdk.java.net/browse/JDK-8227870>) we would like to introduce a new escape sequence that can also be used to govern the presence of the final line terminator. The escape sequence \<line-terminator> indicates that the line terminator is to be ignored/removed. String z = """ Mary had a little lamb Whose fleece was white as snow.\ """; z, in this case, will have the same value as y above. That is. "Mary had a little lamb␊Whose fleece was white as snow.". Comments on specific points inline below. Cheers, -- Jim > Hello, > > > > This ist the first time I'm writing to the OpenJDK devs and I'm not sure if > this is the correct place to do so, I apologise if it isn't. > > I recently saw the <Programmer's Guide To Text Blocks> > (http://cr.openjdk.java.net/~jlaskey/Strings/TextBlocksGuide_v8.html <http://cr.openjdk.java.net/~jlaskey/Strings/TextBlocksGuide_v8.html>). > > First I'm really glad that you moved away from the String Literal proposal > and especially that you're not planning to to use the backtick as marker > anymore. > > The backtick is a dead-key on many keyboards and would be inconvenient to > type. > > > > However I was quite bothered that newlines are added at the end of > textblocks when the end-marker (""") is on a new line. > > > > Is there a good reason for this? > > > > I think developers would have some benefits if it wouldn't do that. In > consequence the end-marker would need to on its own line, the same way as > the start-marker > > needs to be followed by a line-terminator. > > > > - An automatic final newline is often not desirable. E.g. HTML or SQL or > prose that we wish to include as a textblock. Some examples in the > <Programmer's Guide To Text Blocks> seem to be unnaturally constructed to > fit the resulting textblocks. Some of the style guide examples are contrived to make a point, but I believe "unnatural" is countered by my commentary above. It could be that Python leads you to work one way and that Java does it an alternative way. Programming languages are like that. That's why we have so many. > > - The final newline it is even in the way. E.g. Valid Python code or when > concatenating two textblocks. Without newlines at the end, concatenation > would feel similar as we are used to it now. > > - It's harder and inconvenient to remove a newline after creating the > textblock. The textblock will often be used as a static final constant > field. There's is currently no easy way to do this with the JDK alone. It > would require import to org.apache.commons.lang3.StringUtils::chomp. In > contrast it would be easy to add a final newline if it was really required. > Simply adding an empty line before the end-marker. String x = """ Mary had a little lamb␊ Whose fleece was white as snow.␊ """.stripTrailing(); > > - <What you see is what you get>. The resulting String would always entail > the textblock between the markers. If there's a final newline, it would be > clearly visible as a newline in the block. Valid point, but design is a choice. There can be more than one correct answer of equal value. Others might see the extra line as causing the closing delimiter to be disjoint. > > - Singleline textblocks would be visually appealing. It would be and look > consistent with multiline textblocks. You could express indents in > singleline textblocks without having to use String::indent after creation. > > Stripping of leading/trailing blank lines was considered, but blank lines are often desired. We chose be as loss-less as possible. > > For examples: > > private static final String PARAGRAPH = """ > > > <p>"This is a paragraph!"</p> > > """; > > > > Would result in: > > | <p>"This is a paragraph!"</p> > > > > Kind regards, > > > > Simon > > >> On Aug 12, 2019, at 10:26 AM, Brian Goetz <brian.goetz at oracle.com> wrote: >> >> The following comment was received on amber-spec-comments: >> >> https://mail.openjdk.java.net/pipermail/amber-spec-comments/2019-August/000028.html >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20190813/99574a20/attachment-0001.html>