RFR 8194746: (fs) Add equivalents of Paths.get to Path interface

Brian Burkhalter brian.burkhalter at oracle.com
Tue Mar 13 14:42:03 UTC 2018


On Mar 13, 2018, at 7:04 AM, Remi Forax <forax at univ-mlv.fr> wrote:

>> On 08/03/2018 22:52, Brian Burkhalter wrote:
>>> Updated patch with the improvements suggested below:
>>> 
>>> http://cr.openjdk.java.net/~bpb/8194746/webrev.01/
>>> <http://cr.openjdk.java.net/%7Ebpb/8194746/webrev.01/>
>>> 
>> What would you think of trimming the javadoc of the Paths.get methods so
>> that it is more obvious that they just delegate to Path.get?
> 
> yes !

Roger also suggested that off line and it was actually what I wanted to do in the first place but did not do it.

>> Separately, Brian Goetz suggested off-list that it would be more
>> consistent if these factory methods were named "of" so I assume the
>> webrev will be updated to see how that looks.
> 
> any name will be better than "get", and yes the recent vogue is to use "of",
> you can also use "path" if you suppose people will use an import static, "of" doesn't well with an import static.

I was thinking about this and “of” in this case does not seem in complete analogy to for example {List,Set,Stream}.of(). If these cases are denoted X.of(x1,x2,…), they create a container of type X whose contents are {x1,x2,…}. In the case of Path, the arguments of the current get() methods are used to create a Path but are not exactly members as in the case of X.of(). In any case I am happy to update the proposal (webrev + specdiff) to whatever achieves consensus.

Thanks,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20180313/9c412204/attachment-0001.html>


More information about the nio-dev mailing list