Fair enough. I'll be less unhappy if there is a way to convert from a code
point to a String, as requested by JDK-4993841. This will reduce
new String(Character.toChars(codepoint)).repeat(count)
to
Character.toString(codepoint).repeat(count)
But this is still fairly roundabout. Since most cases are constants, the advice
is to use a string literal instead of a char literal. This works for BMP
characters, e.g. "-".repeat(10) or "\u2501".repeat(15). But if I want a non-BMP
character as a string literal, I have encode it into a surrogate pair myself.
For example, a string literal containing the character U+1D11A MUSICAL SYMBOL
FIVE-LINE STAFF would be "\uD834\uDD1A". Ugh! Or, I could just call a function
and live with it not being a constant. It would be nice if there were an escape
sequence that allowed any Unicode code point, including supplementary
characters, to be put to n a string literal.
s'marks
> On Feb 16, 2018, at 18:02, Brian Goetz <[email protected]> wrote:
>
> Disagree.
>
> On #3, most of the time the char being repeated is already a literal. So
> just make it a string.
>
> On #2, better to aim for string.ofCodePoint(int) and compose w repeat.
>
> Down to one method again :)
>
> Sent from my MacBook Wheel
>
>> On Feb 16, 2018, at 5:13 PM, Stuart Marks <[email protected]> wrote:
>>
>> Let me put in an argument for handling code points:
>>
>>> 3. public static String repeat(final int codepoint, final int count)
>>
>> Most of the String and Character API handles code points on an equal footing
>> with chars. I think this is important, as over time Unicode is continuing to
>> add supplementary characters -- those that can't be represented in a Java
>> char value. Examples abound of how such characters are mishandled.
>> Therefore, I believe Java APIs should have full support for code points.
>>
>> This is a small thing, and some might consider it a rare case -- how often
>> does one need to repeat something like an emoji? The issue however isn't
>> that particular use case. Instead what's required is the ability to handle
>> *any Unicode character* uniformly, regardless of whether or not it's a
>> supplementary character. The way to do that is to deal with code points, so
>> any Java API that deals with character data must also handle code points.
>>
>> If we were to add just one method:
>>
>>> 1. public String repeat(final int count)
>>
>> the workaround is to take the character, turn it into a string, and call the
>> repeat() method on it. For a 'char' value, this isn't too bad, but I'd argue
>> it isn't pretty either:
>>
>> Character.toString(charVal).repeat(n)
>>
>> But this only handles BMP characters, not supplementary characters.
>> Unfortunately, there's no direct way to turn a code point into a string --
>> you have to turn it into a byte array first! Thus, to get a string from a
>> code point and repeat it, you have to do this:
>>
>> new String(Character.toChars(codepoint)).repeat(count)
>>
>> This is enough indirection that it's hard to discover, and I suspect that
>> most people won't put in the effort to do this correctly, resulting in more
>> code that mishandles supplementary characters.
>>
>> Thus, I think we need to add API #3 that performs the repeat function on
>> code points.
>>
>> (Hm, the lack of Character.toString(codepoint) is covered by JDK-4993841,
>> which is closed. I think I'll reopen it.)
>>
>>> 2. public static String repeat(final char ch, final int count)
>>
>> I can see that this API is not as important as one that handles code points,
>> and it seems to be less frequently used according to Louis W's analysis. But
>> if you have char data you want to repeat, not having this seems like an
>> omission; it seems backwards to have to create a string from the char, only
>> for repeat() to extract that char from that String in order to repeat it.
>> Thus I've vote for inclusion of this method as well.
>>
>> s'marks
>>
>>
>>> On 2/16/18 5:10 AM, Jim Laskey wrote:
>>> We’re going with the one instance method (Louis clinched it.) with
>>> recommended enhancements and not touching CharSequence.
>>> Working it up now.
>>> — Jim
>>>> On Feb 16, 2018, at 7:46 AM, Alan Bateman <[email protected]> wrote:
>>>>
>>>> On 15/02/2018 17:20, Jim Laskey wrote:
>>>>> This is a pre-CSR code review [1] for String repeat methods (Enhancement).
>>>>>
>>>>> The proposal is to introduce four new methods;
>>>>>
>>>>> 1. public String repeat(final int count)
>>>>> 2. public static String repeat(final char ch, final int count)
>>>>> 3. public static String repeat(final int codepoint, final int count)
>>>>> 4. public static String repeat(final CharSequence seq, final int count)
>>>>>
>>>> Just catching up on this thread and it's hard to see where the bidding is
>>>> currently at. Are you planning to send an updated proposal, a list of
>>>> methods is fine, even if it's just one, is okay (implementation can follow
>>>> later).
>>>>
>>>> -Alan
>>
>
