Re: Raw String Literal Library Support

One more change set. trimIndent -> stripIndent trimMarkers -> stripMarkers > On Mar 20, 2018, at 10:35 AM, Jim Laskey wrote: > > Summary. > > A. Line support. > > - Supporting a mix of line terminators `\n|\r\n|\r` is already a well > established pattern in

Re: Raw String Literal Library Support

Summary. A. Line support. - Supporting a mix of line terminators `\n|\r\n|\r` is already a well established pattern in language parsers, in the JDK (ex. see java.nio.file.FileChannelLinesSpliterator) and RegEx (ex. see `\R`). The performance difference between checking one vs the three is

Re: Raw String Literal Library Support

On Fri, Mar 16, 2018 at 8:58 AM, Stephen Colebourne wrote: > On 14 March 2018 at 23:05, Michael Hixson wrote: >> For example, does ``.lines() produce an empty stream? > > I believe `` is a compile error. > (A mistake IMO, but necessary if you have

Re: Raw String Literal Library Support

On 14 March 2018 at 23:05, Michael Hixson wrote: > For example, does ``.lines() produce an empty stream? I believe `` is a compile error. (A mistake IMO, but necessary if you have unlimited delimiters) Stephen

Re: Raw String Literal Library Support

On 13/03/2018 13:47, Jim Laskey wrote: : We are recommending that trimLeft and trimRight use UWS, leave trim alone to avoid breaking the world and then possibly introduce trimWhitespace that uses UWS. Right, it would too risky to change rim() as it goes all the way back to JDK 1.0. If you

Re: Raw String Literal Library Support

On 14 March 2018 at 23:55, Stuart Marks wrote: > So, how about we define trimLeft, trimRight, and trimWhitespace > all in terms of Character.isWhitespace? This seems like a reasonable approach. I'd expect tab to be trimmed for example. Commons-Lang is a good source to

Re: Raw String Literal Library Support

Hi Jim, Some comments (really, mainly just quibbles) about string trimming. First, * String.trim trims characters <= \u0020 from each end of a string. I agree that String.trim should be preserved unchanged for compatibility purposes. * The trimLeft, trimRight, and trimWhitespace (which trims

Re: Raw String Literal Library Support

Hi Jim, Does string.lines() agree with new BufferedReader(new StringReader(string)).lines() on what the lines are for all inputs? For example, does ``.lines() produce an empty stream? -Michael On Tue, Mar 13, 2018 at 6:47 AM, Jim Laskey wrote: > With the announcement

Re: Raw String Literal Library Support

xueming.s...@oracle.com>, "core-libs-dev" > <core-libs-dev@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

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

Re: Raw String Literal Library Support

On Mar 14, 2018, at 6:11 AM, Peter Levart wrote: > > 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? There's no

Re: Raw String Literal Library Support

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

Re: Raw String Literal Library Support

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

Re: Raw String Literal Library Support

Sorry, I should really run things in an IDE before posting code examples and results! For examples ":".split(":", 0) and "".split(":", 0), they actually produce [] and [""] respectively (which I still argue is inconsistent and undesired for the proposed String.splits()). For examples

Re: Raw String Literal Library Support

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

Re: Raw String Literal Library Support

> On Mar 13, 2018, at 3:49 PM, John Rose wrote: > > On Mar 13, 2018, at 6:47 AM, Jim Laskey wrote: >> >> … >> A. Line support. >> >> public Stream lines() >> > > Suggest factoring this as: > > public Stream splits(String regex) { } +1

Re: Raw String Literal Library Support

On Mar 13, 2018, at 6:47 AM, Jim Laskey wrote: > > … > A. Line support. > > public Stream lines() > Suggest factoring this as: public Stream splits(String regex) { } public Stream lines() { return splits(`\n|\r\n?`); } The reason is that "splits" is useful with

Re: Raw String Literal Library Support

On Mar 13, 2018, at 11:30 AM, Volker Simonis wrote: > > Would it make sense to have a versions of "lines(LINE_TERM lt)" which > take a single, concrete form of line terminator? (Regular expressions for the win!)

Re: Raw String Literal Library Support

On Mar 13, 2018, at 11:42 AM, Remi Forax wrote: > > it already exists :) > Stream stream = Pattern.compile("\n|\r\n|\r").splitAsStream(string); You want ` instead of " there! Somebody added support recently for `\R`, which is a more unicode-flavored version of your pattern

Re: Raw String Literal Library Support

On 14 Mar 2018, at 7:42, Remi Forax wrote: > it already exists :) > Stream stream = Pattern.compile("\n|\r\n|\r").splitAsStream(string); > > Rémi One that worked, or had support for grey-space would be a nice addition when working with RSL tho, unless grey-space is automatically handled at

Re: Raw String Literal Library Support

Hi Jim, - Mail original - > De: "Jim Laskey" <james.las...@oracle.com> > À: "core-libs-dev" <core-libs-dev@openjdk.java.net> > Envoyé: Mardi 13 Mars 2018 14:47:29 > Objet: Raw String Literal Library Support > With the announcement of JEP

Re: Raw String Literal Library Support

On Tue, Mar 13, 2018 at 2:47 PM, Jim Laskey wrote: > With the announcement of JEP 326 Raw String Literals, we would like to open > up a discussion with regards to RSL library support. Below are several > implemented String methods that are believed to be appropriate.

Raw String Literal Library Support

With the announcement of JEP 326 Raw String Literals, we would like to open up a discussion with regards to RSL library support. Below are several implemented String methods that are believed to be appropriate. Please comment on those mentioned below including recommending alternate names or