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 language parsers, in the JDK (ex
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 neg
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 unlimited delimiters)
Ah, oops. I meant to ask
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
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 i
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 consider when looking at na
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
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 of JEP 326 Raw String Liter
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"
> À: "Peter Levart" , "Xueming Shen"
> , "core-libs-dev"
>
> Envoyé: Mercredi 14 Mar
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
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 need to introduce syntax
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 dynam
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/StringSp
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 ":".split(":
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 surpri
> 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
This is a natural companion to the existing array re
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 several other patterns.
For
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!)
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 (or just `\n`). Las
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 the
Hi Jim,
- Mail original -
> De: "Jim Laskey"
> À: "core-libs-dev"
> Envoyé: Mardi 13 Mars 2018 14:47:29
> Objet: 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. Bel
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. Please
> comment on those m
22 matches
Mail list logo