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