On 4/10/2018 5:18 PM, Kevin Bourrillion wrote:
On Tue, Apr 10, 2018 at 1:50 PM, Brian Goetz <brian.go...@oracle.com
<mailto:brian.go...@oracle.com>> wrote:
3. If the input contains *any* tab characters at all (except
any that are
part of the trailing whitespace), then this method cannot know
that it
isn't jumbling the end result, and maybe it should just throw.
I think there's a middle ground, where it strips any common
whitespace prefix. So if every line starts with
tab-tab-space-space, it can safely strip this.
My point is that this is /not/ safe, if by "safe" we mean "you will
see the same relative indentation you saw in the source". /Any/ tab
has the potential to suddenly be worth a different number of spaces,
once some prefix of any kind has been removed.
That's not what I mean by safe. I mean that one could have reasonably
predicted what string was going to result. Developers who use randomly
mixed spaces and tabs do not deserve to see the same relative indentation.
While I personally dislike tabs, I accept that some people like them,
and if used responsibly and consistently, we can all get along. But
using them inconsistently across lines of a multiple-line expression, or
using them after leading spaces, are not high on my list of situations
we should cater to.
5. If we do end up in a world where we have to call this for
almost every
one of our tens of thousands of multi-line RSLs... is it
strange that I
feel like I would prefer it was static? It seems like it would
look a lot
more normal that way visually. Ugh...
I think this is likely to vary subjectively a lot. Some people
like that the instance method is mostly out of the way; others
like the up-front shouting of the static method.
Is it just potayto, potahto, or does one of the snippets above appear
a lot more consistent with how Java code has always looked?
I think its pota{y,h}to as to which is more likely to trigger
indignation at the compiler for having forced them to muck up their
code. And, a certain degree of fashion; chaining is "in" these days.
