On 05/23/2016 02:31 PM, Stuart Marks wrote:
On 5/20/16 4:59 PM, Jonathan Gibbons wrote:
While I would agree on the use of one type, not two, for file paths,
I would
question the choice to use String instead of Path. If something is a
file path,
use the type system to say so, and use a Path.
Sure, either way will work. I had started with String because the data
originates as strings, either from system properties or from string
literals.
I switched things around to see what things looked like, starting with
Path and converting to String as necessary. Basically I declared the
constants using Paths.get(). This meant fileJoin() could disappear,
since Paths.get() can concatenate multiple elements.
Paths.get() disappeared from several places inline, and was replaced
with a chain of calls to resolve() in a couple others. I had to add
toString() in a few places as well.
The pathJoin() helper had to change a bit though. Formerly it
concatenated strings with File.pathSeparator; now it has to convert
Path objects to strings before doing so. The easiest way to do this
was to use a short stream:
static String pathJoin(Path... paths) {
return Arrays.stream(paths)
.map(Path::toString)
.collect(Collectors.joining(File.pathSeparator));
}
Overall I'd say six of one, half a dozen of the other.
s'marks
Yes, and the example is small enough that maybe six of one really does
balance half a dozen of the other. But as a general matter of style, I
think it is preferable to use Path when you really want paths.
That being said, it would be nice to have a method on the Paths API to
create a search path from a series of Path objects. (your pathJoin method)
-- Jon
