Scala：特征扩展了java.nio.file.FileVisitor

Question

I learn new things in Scala everyday. The current route I am taking is to pull out functionality from java nio and make Scala implementations out of them. I have observed how other Scala experts are using the java.nio.files package, and the FileVisitor interface to recursively walk down a nested directory structure with sub-directories and files.

But, I have run into a slight problem. I cannot quite make sense of

I noticed an implementation on github maintained by paulp, that I cannot understand.It is his code that I will present here, with my questions and concerns:

import java.nio.file.{ FileVisitResult, SimpleFileVisitor }

      trait PathVisitor extends FileVisitor[Path] {
         def preVisitDirectory(dir: Path, attrs: BasicFileAttributes): FileVisitResult
         def postVisitDirectory(dir: Path, exc: IOException): FileVisitResult
        def visitFile(file: Path, attrs: BasicFileAttributes): FileVisitResult
        def visitFileFailed(file: Path, exc: IOException): FileVisitResult
     }

Okay, he extends from FileVisitor, which is a Java interface: At first, I was not sure if a Scala trait can extend from a java interface. I tested this out in the REPL. Apparently this is Okay. REPL output is below:

C:\\Users\\lulu\\Documents\\GitHub\\akkaexperiments>scala Welcome to Scala version 2.10.2 (Java HotSpot(TM) 64-Bit Server VM, Java 1.7.0_71). Type in expressions to have them evaluated. Type :help for more information.

scala> import java.nio.file.{ FileVisitor }; import java.nio.file.FileVisitor

scala> import java.nio.file.Path import java.nio.file.Path

scala> trait PathVisitor extends FileVisitor[Path] defined trait PathVisitor

scala>

---

With that out of the way, I now looked at the source for FileVisitor.java. Here it is below: This is where paulp is intriguing. Explanation follows after the below code.

  public interface FileVisitor<T> {
        FileVisitResult preVisitDirectory(T dir);

        FileVisitResult preVisitDirectoryFailed(T dir, IOException exc);

         FileVisitResult visitFile(T file, BasicFileAttributes attrs);

         FileVisitResult visitFileFailed(T file, IOException exc);

         FileVisitResult postVisitDirectory(T dir, IOException exc);

      }

---------------------

paulp's code continues below:

    object PathVisitor {
      class Simple extends SimpleFileVisitor[Path] with PathVisitor { }

      val Continue     = FileVisitResult.CONTINUE
      val SkipSiblings = FileVisitResult.SKIP_SIBLINGS
      val SkipSubtree  = FileVisitResult.SKIP_SUBTREE
      val Terminate    = FileVisitResult.TERMINATE

      def apply(f: (Path, BasicFileAttributes) => FileVisitResult): PathVisitor = new Simple {
        override def visitFile(file: Path, attrs: BasicFileAttributes):  FileVisitResult = f(file, attrs)
      }

    }

------

For context and comparison purposes here is the code for SimpleFileVisitor:

     public class SimpleFileVisitor<T> implements FileVisitor<T> {

           protected SimpleFileVisitor() {
          }

          @Override
         public FileVisitResult preVisitDirectory(T dir, BasicFileAttributes attrs)
        throws IOException
        {
           Objects.requireNonNull(dir);
           Objects.requireNonNull(attrs);
           return FileVisitResult.CONTINUE;
        }

         @Override
    public FileVisitResult visitFile(T file, BasicFileAttributes attrs)
        throws IOException
    {
        Objects.requireNonNull(file);
        Objects.requireNonNull(attrs);
        return FileVisitResult.CONTINUE;
    }

    @Override
    public FileVisitResult visitFileFailed(T file, IOException exc)
        throws IOException
    {
        Objects.requireNonNull(file);
        throw exc;
    }

   @Override
    public FileVisitResult postVisitDirectory(T dir, IOException exc)
        throws IOException
    {
        Objects.requireNonNull(dir);
        if (exc != null)
            throw exc;
        return FileVisitResult.CONTINUE;
    }  

}

---

After all this, I make the following observations: class Simple extends SimpleFileVisitor, which is an implementation of the Java FileVisitor interface

Also paulp mixes in trait PathVisitor, whose method definitions are exactly the same as the ones in the Java FileVisitor interface.

What is the baffling to me here is: 1) why did he extend SimpleFileVisitor at the same time as he also mixes in the PathVisitor trait? 2) Are we not trying to ask class Simple to honor both SimpleVisitor contract and FileVisitor trait unimplemented methods, when they are the same methods? 3) He wraps the Simple Class, a bunch of vals to represent the return types of the SimpleFileVisitor methods and an apply method. Okay, so what do you think is the idea behind this kind of structure?

I would really like to use the structure laid out by PaulP, but this is baffling. It needs some cleanup perhaps. Please advise.

Answer 1

The reason to do things this way is to provide a seamless Scala experience. First, instead of abstracting over whichever T you might have a visitor for, the first trait specifies paths. If you're really only interested in paths, it's nice to not have to worry about generics.

Then he provides the constants for you in Scala style so you don't have to grab them from Java.

And he gives you a Path-specific SimpleFileVisitor without any extra work by just mixing in the PathVisitor trait.

Now, the question remains: why do this rather than just say

type PathVisitor = java.nio.file.FileVisitor

There are two reasons. First, types aliases aren't really first-class language constructs, so you'll tend to see the Java type instead of the Scala one (slightly less nice). Also, if you set it up this way you can more easily add functionality into the framework later. If you're sure you won't want to add anything, there's less argument to do it this way.

Now, for specific questions:

1. We mix in PathVisitor so we have a Scala-specific type that we can move around and manipulate; we get the implementations from the Java SimpleFileVisitor but make it pick up the Scala trait.

2. Asking to honor multiple methods which match isn't a problem; the same method can be part of the API of multiple traits. The key is whether you can use the trait you want (ie PathVisitor; answer is "yes").

3. Scala-style constants provided locally help clean up your imports and provides a more seamless experience, as does the apply -style builder instead of new .