OK, I understand the need for quoting, although I wonder how many folk
have bothered with that up to now (looking at javac, jtreg!) ;-)
I'd stay with
List<Path> getList(String searchPath)
and then either have people use
getList(searchPath).stream().map(Path::toString).collect(Collectors.toList())
or if we want the extra method, then
List<String> getListAsStrings(String searchPath)
-- Jon
On 09/10/2018 01:55 PM, Roger Riggs wrote:
Hi Jon,
On 9/10/2018 4:47 PM, Jonathan Gibbons wrote:
Roger,
I had in mind your first "disambiguate" suggetion
(searchPathToStrings, searchPathToPaths)
but I note your initial comment "Is the search path the input string
or the return value? Well its both, but with different structure. "
Since we have
Paths.get
how about
List<Path> Paths.getList(String searchPath)
Not bad, but...
Perhaps, List<String> Paths.getListAsStrings(String searchPath)...
I'd be less inclined to give formal support to converting to a
List<String>. Those folk that want that could/should
be using String.split(File.pathSeparator) or something like that.
Nope! there's quoting on Windows that gets short changed with that
work around.
Other opinions?, Suggestions?
Thanks, Roger
-- Jon
On 09/10/2018 01:34 PM, Roger Riggs wrote:
Hi Jon, Alan,
No surprise and suggestions welcome! :)
Since we don't have return type overloads, the name has to encode
the return type (or the important aspects of it).
Is the search path the input string or the return value? Well its
both, but with different structure.
Remove the ambiguity:
* a) Drop one of the APIs, leaving only the return of List<String> and
push the conversion to Path to the consumer.
e.g. List<Path> files = toSearchPath(String).stream().map(s ->
Paths.of(s)).collect(Collectors.toList());
* b) Drop the other API, always doing the conversion to Path and
throwing exceptions.
e.g. List<Path> toSearchPath(String);
The Caller can get the string or file by calling toString() or
toFile(); potentially wasting the effort to check the path syntax.
Disambiguate:
* List<String> searchpathToStrings(s); List<Path>
searchpathToPaths(s); or
var files = Paths.searchpathToStrings("a;b;c");
var searchpath = Paths.searchpathToPaths("x;y;z");
* List<Path> toPathList(String searchpath); List<String>
toStringList(String searchpath)
Without static imports looks like:
var files = Paths.toStringList("a;b;c").stream()....
var searchpath = Paths.toPathList("x;y;z");
* ???
Thanks, Roger
On 9/10/2018 2:28 PM, Jonathan Gibbons wrote:
Roger,
You've run into the standard naming ambiguity problem of "when is a
path a search path, with elements separated by File.pathSeparator
(e.g. class path, source path), and when is it a file path, with
elements separated by File.separator (e.g. a nio.file.Path
identifying a file or directory)?"
This shows up most obviously in the method confusingly named
"pathToPaths".
In other contexts (javac, jtreg, etc) I've tried to use the term
"search path" to describe the string that is a sequence of elements
separated by File.pathSeparator.
-- Jon
On 9/10/18 11:16 AM, Roger Riggs wrote:
Please review the API and implementation of an API to parse Path
strings.
Two methods are added to java.nio.file.Paths to parse a string
using the path separator delimiter
and return either List<String> or List<Path>. Empty path elements
are ignored.
For compatibility with current URLClassPath behavior the internal
implementation handles
replacement of empty paths.
Webrev:
http://cr.openjdk.java.net/~rriggs/webrev-8207690_parsing_api_for_classpath_and_similar_path_strings/
CSR:
https://bugs.openjdk.java.net/browse/JDK-8208208
Thanks, Roger
