String reboot - (1a) incidental whitespace
Alex Buckley
alex.buckley at oracle.com
Tue Apr 23 00:00:29 UTC 2019
On 4/22/2019 12:16 PM, Guy Steele wrote:
>> On Apr 22, 2019, at 3:04 PM, Alex Buckley <alex.buckley at 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
More information about the amber-spec-experts
mailing list