Path("path/to/file") no longer works in scala-io 0.3.0

[Jeff Olson]

I noticed the 0.3.0 release of scala-io and I tried upgrading, but I immediately ran into this problem. The FileSystem throws:

java.lang.IllegalArgumentException: / is not permitted as a path segment for this filesystem

Path.fromString("path/to/file") works as expected but is highly inconvenient.

Please tell me this is a bug and not the new way of doing things.

-Jeff

[Jesse Eichar]

Sorry to say that it is not a bug.  The reason is because using strings like that results in non-portable code where as Path("path","to","file") is portable.  

That said it is only 0.3.0 so all issues are open for discussion.  I could see the option: Path("a/b/c","/") as a way to create paths in a portable manner. But right now you can do:

Path.fromSeq("a/b/c".split("/"))

In my experience I have found that using File almost always results in non-portable code because the separators are always in the strings.  So i have most frequently seen the following:

String sep = File.separator

new File("a"+sep+"b"+sep+"c")

terrible.  I am trying to not make the same mistake.  If the developer wants to make a Path from a string they have to be explicit.

That is my reasoning.

Jesse

[Jeff Olson]

I was afraid you were going to say that.

What about something like:

object Path {

  def apply(path: String)(implicit fileSystem: FileSystem = FileSystem.default): Path =

    fileSystem.fromSeq(path.split(fileSystem.separator))

}

I just really, really want to Path("path/to/file") to just work without any extra (mandatory) syntax.

[Jeff Olson]

Or maybe something a little more flexible like

object Path {

  def apply(path: String)(implicit fileSystem: FileSystem = FileSystem.default, sep: Option[Separator] = None): Path =

    fileSystem.fromSeq(path.split(sep.getOrElse(fileSystem.separator)))

}

[Jesse Eichar]

I can understand why you want less syntax. But as an API designer I am thinking that that will be the first and likely last method a new user will look and by having that as the "default" factory method much/most code will be non-portable like the java.io.File code.  If I add that (fairly) minor syntax (fromString) then much more code will be portable.  

... Trying to stay open minded and not too much in love with my decision...  

Supposing that we have the more flexible solution like you proposed people would see the extra parameter and perhaps be more likely to write it in a portable manner...  I still have to think that is not the case.  Most likely they will just ignore it and write non-portable code.

I do agree that Path("a","b","c") is annoying because of extra cruft.  But I am having a hard time bringing myself to defaulting to Path.separator

Jesse

Sent from my iPad