> On 11 Sep 2018, at 14:18, Roger Riggs <[email protected]> wrote: > > Hi Chris, > > On 9/11/18 7:50 AM, Chris Hegarty wrote: >>> On 11 Sep 2018, at 10:24, Alan Bateman <[email protected]> wrote: >>> >>> On 10/09/2018 21:55, Roger Riggs wrote: >>>> Nope! there's quoting on Windows that gets short changed with that work >>>> around. >>>> >>>> Other opinions?, Suggestions? >>> One suggestion is reduce this down to one method that returns a stream >>> rather than a collection. It could work lazily if you want. Something like: >>> >>> Stream<String> splitSearchPath(String input) >> I agree with Alan, this seems like the lowest-order primitive. > How can that be? The Stream creates a lot more objects and takes even more to > use it.
I guess it depends on the use-case that you are trying to address. In the cases that I sited, a Stream would likely be more appropriate since the calling code requires to iterate over the entries, rather than store them as-is. You are probably thinking of different use-cases. > It can't be stored or re-used and has higher overhead that can't easily be > understood. .collect(toList()) - which, again, depending on use-case may be more or less common than entries.stream(). >> I refreshed my memory of search path splitting from the `jmod` tool, >> where such an API would be useful ( if we weren’t using joptsimple ). >> There are two separate use cases, ClassPathConverter, and >> DirPathConverter ( in JmodTask ), both of which resolve each String >> path value against the current working directory, and do some >> context specific validation. > Command line tools are more likely to resolve against the current directory > List<String> is least common but still pushes more to the developer. Exactly. My comments are from the perspective of writing a command line tool, since that is the only direct experience I have with such functionality. You may have different use- cases in mind. -Chris.
