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.san...@oracle.com> wrote:
On Mar 13, 2018, at 3:49 PM, John Rose<john.r.r...@oracle.com> wrote:
On Mar 13, 2018, at 6:47 AM, Jim Laskey<james.las...@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.