[RSL] RSL update

[Kevin Bourrillion]

On Tue, Jun 26, 2018 at 5:09 AM Brian Goetz <brian.goetz at oracle.com> wrote:

> Here are two more arguments in favor of language-level stripping:
>
> 1. Strings inside annotations aren't left out. Whenever an annotation
> attribute feels like something users may want to use an RSL for, the best
> we can hope for (if we don't have automatic unindenting) is for the
> specification of that attribute to say "consumers of this data *really
> should* call .align() on this" - quite unsatisfying, and we can be sure
> most annotation specs won't bother.
>
> This seems like a pretty corner^3 case to me; long strings in annotations
> are kind of questionable already, multi-line strings in an annotation seem
> even more so,
>

Huh. I don't personally see a reason to devalue this use case. It occurs
tens of thousands of times for us, but I will try to look into them to see
whether they are questionable in some way.



> and in those cases where you absolutely need to be divorced from the
> incidental indentation, you could just align it yourself correctly, at the
> cost of uglier indentation (or pull it out into a static var.)
>

I think these workarounds are fair but are still both a little sad.


By leaving it to the user, they are free to put the align where it belongs:
>

> String s = (`
>   - person:
>      - name: /` + name + `/
>      - age: 127`).align();
>

I have a broader response to this bit, but first I want to drill in just on
this workaround a bit. So let's assume we've gone with the
library-unindenting option.

The workaround exists, but first users will fall into the pit before they
realize what went wrong. Is this reason enough that we should change
`align` to a static method? That actually makes this problem more or less
vanish.

That said, I wonder if users are better served by switching to
`String.format` whenever possible, anyway. They should .align() the format
string instead of the formatted result. It's more foolproof, and they still
get the benefit of align() happening at (compile time? load time? whenever
the new magic happens). Output will be consistent even if a piece of data
unexpectedly contained a newline.  I'm roughly expecting to be giving users
the advice to avoid mixing RSLs with concatenation altogether.

-- 
Kevin Bourrillion | Java Librarian | Google, Inc. | kevinb at google.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20180626/69c310d3/attachment.html>