On 4/22/2019 12:16 PM, Guy Steele wrote:
On Apr 22, 2019, at 3:04 PM, Alex Buckley <alex.buck...@oracle.com>
wrote:
Nope, I don't think multi-line string literals are an attractive
nuisance in any way. We should NOT deem it incorrect to refactor a
sequence of concatenations into a single multi-line string
literal.
I didn’t say (or mean to imply that). I think it’s a great thing to
refactor concatenations into a single multi-line string literal WHEN
IT IS DONE CORRECTLY.
However, if you blindly pull out the concatenations and thereby
introduce newlines into the string when they were not there before
and doing so violates some contract downstream, THAT IS AN INCORRECT
TRANSFORMATION.
Literally, yes, it's an incorrect transformation for the caller to
perform if it violates the contract offered by the callee.
We certainly agree that it would be a good thing if everything that
might be downstream were in fact reasonably tolerant of newlines.
Yes.
BUT IF YOU DON’T KNOW FOR SURE THAT WHAT IS DOWNSTREAM IS TOLERANT OF
NEWLINES, AND YOU BLINDLY TRANSFORM A STRING CONCATENATION INTO A
MULTI-LINE STRING LITERAL THAT INCLUDES NEWLINES WHERE THERE WERE
NONE BEFORE, THAT IS A BAD THING.
If the callee's contract says "No newlines in the string argument to
Customer::setName", then the caller would be doing a bad thing.
But the reason this topic is interesting(ish) is because we're dealing
with something that the vast majority of callees never thought to specify.
(Well, maybe not "never". I browsed the Java SE API Specification to
find a method that takes a String, and randomly clicked on something in
JNDI --
https://docs.oracle.com/en/java/javase/12/docs/api/java.naming/javax/naming/Name.html#add(java.lang.String)
-- which happens to be strict about the string passed to it, so perhaps
someone is about to get an InvalidNameException when they try to lay out
a long LDAP query string over multiple lines.)
And a feature that makes it too easy to accidentally do a bad thing
_might_ be considered an attractive nuisance, AS OPPOSED TO MY
SCREAMING ALL-CAPS, WHICH ARE A REPULSIVE NUISANCE.
I can get 90% of the way to saying "OK, multi-line string literals
_might_ be considered an attractive nuisance", but I can't get 100% of
the way there because it's such a callee-centric view to take when the
purpose of the feature is to simplify the life of the caller. If you
crack open the door to give callees a hearing, you'll get requests to
statically reject multi-line string literals (such as via a java.*
annotation that programmatically indicates "not multi-line safe", or a
java.lang.MultilineString type that's a sibling of String) and we don't
want to go anywhere near there.
(I recall a library that took Runnable or somesuch, and fell over when
the argument was a lambda expression; the library expected an anonymous
inner class instance in order to do some peculiar introspection, which
failed on the opaque object reifying a lambda expression. The library
developer _might_ have considered lambda expressions an attractive
nuisance for a few minutes, but who would have sympathy?)
Alex
