Raw String Literal Library Support

[Remi Forax]

doh,
sorry for the tangential comment, it was the only comment i had, all other methods are fine.

Rémi

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Peter Levart" <peter.levart at gmail.com>, "Xueming Shen" <xueming.shen at oracle.com>, "core-libs-dev"
> <core-libs-dev at openjdk.java.net>
> Envoyé: Mercredi 14 Mars 2018 16:26:30
> Objet: Re: Raw String Literal Library Support

> Perhaps we can "split" this discussion on splitting into a separate
> thread.  What's happened here is what always happens, which is:
> 
>  - Jim spent a lot of time and effort writing a comprehensive and clear
> proposal;
>  - Someone made a tangential comment on one aspect of it;
>  - Flood of deep-dive responses on that aspect;
>  - Everyone chimes in designing their favorite method not proposed;
>  - No one ever comes back to the substance of the proposal.
> 
> Hitting the reset button...
> 
> 
> On 3/14/2018 9:11 AM, Peter Levart wrote:
>> I think that:
>>
>> String delim = ...;
>> String r =
>> s.splits(Pattern.quote(delim)).collect(Collectors.joining(delim));
>>
>> ... should always produce a result such that r.equals(s);
>>
>>
>> Otherwise, is it wise to add methods that take a regex as a String? It
>> is rarely needed for a regex parameter to be dynamic. Usually a
>> constant is specified. Are there any plans for Java to support Pattern
>> constants? With constant dynamic support they would be trivial to
>> implement in bytecode. If there are any such plans, then the methods
>> should perhaps take a Pattern instead.
>>
>> syntax suggestion:
>>
>> '~' is an unary operator for bit-wise negation of integer values. It
>> could be overloaded for String(s) such that the following two were
>> equivalent:
>>
>> ~ string
>> Pattern.compile(string)
>>
>> Now if 'string' above is a constant, '~ string' could be a constant
>> too. Combined with raw string literals, Pattern constants could be
>> very compact.
>>
>>
>> What do you think?
>>
>> Regards, Peter
>>
>> On 03/14/2018 02:35 AM, Xueming Shen wrote:
>>> On 3/13/18, 5:12 PM, Jonathan Bluett-Duncan wrote:
>>>> Paul,
>>>>
>>>> AFAICT, one sort of behaviour which String.split() allows which
>>>> Pattern.splitAsStream() and the proposed String.splits() don't is
>>>> allowing
>>>> a negative limit, e.g. String.split(string, -1).
>>>>
>>>> Over at http://errorprone.info/bugpattern/StringSplitter, they argue
>>>> that a
>>>> limit of -1 has less surprising behaviour than the default of 0,
>>>> because
>>>> e.g. "".split(":") produces [] (empty array), whereas ":".split(":")
>>>> produces [""] (array with an empty string), which IMO is not
>>>> consistent.
>>>>
>>>> This compares with ":".split(":", -1) and "".split(":", -1) which
>>>> produce
>>>> ["", ""] (array with two empty strings, each representing ends of
>>>> `:`) and
>>>> [] (empty array) respectively - more consistent IMO.
>>>>
>>>> Should String.splits(`\n|\r\n?`) follow the behaviour of
>>>> String.split(...,
>>>> 0) or String.split(..., -1)?  I'd personally argue for the latter.
>>>
>>> While these look really confusing, but ":".split(":", n) and
>>> "".split(":", n) are really two
>>> different scenario. One is for a matched delimiter and the other is a
>>> split with no
>>> matched delimiter, in which the spec specifies clearly that it
>>> returns the original string,
>>> in this case the empty string "". Arguably these two don't have to be
>>> "consistent".
>>>
>>> Personally I think the returned list/array from string.split(regex,
>>> -1) might be kinda of
>>> "surprising" for end user, in which it has a "trailing" empty string,
>>> as it appears to be
>>> useless in most use scenario and you probably have to do some special
>>> deal with it.
>>>
>>> -Sherman
>>>
>>>
>>>
>>>>
>>>> Cheers,
>>>> Jonathan
>>>>
>>>> On 13 March 2018 at 23:22, Paul Sandoz<paul.sandoz at oracle.com>  wrote:
>>>>
>>>>>
>>>>>> On Mar 13, 2018, at 3:49 PM, John Rose<john.r.rose at oracle.com>
>>>>>> wrote:
>>>>>>
>>>>>> On Mar 13, 2018, at 6:47 AM, Jim Laskey<james.laskey at oracle.com>
>>>>>> wrote:
>>>>>>> …
>>>>>>> A. Line support.
>>>>>>>
>>>>>>> public Stream<String>  lines()
>>>>>>>
>>>>>> Suggest factoring this as:
>>>>>>
>>>>>> public Stream<String>  splits(String regex) { }
>>>>> +1
>>>>>
>>>>> This is a natural companion to the existing array returning method
>>>>> (as it
>>>>> was the case on Pattern when we added splitAsStream), where one can
>>>>> use a
>>>>> limit() operation to achieve the same effect as the limit parameter
>>>>> on the
>>>>> array returning method.
>>>>>
>>>>>
>>>>>> public Stream<String>  lines() { return splits(`\n|\r\n?`); }
>>>>>>
>>>>> See also Files/BufferedReader.lines. (Without going into details
>>>>> Files.lines has some interesting optimizations.)
>>>>>
>>>>> Paul.
>>>