I wasn't originally going to change these to make the scope of the pull request as small as possible (given the size of the diff), but the tests weren't passing (file-seq not being on the generated file) even though the method was being implemented. I figured changing them to be function calls would work, and it did. (I'm not 100% as to the internals of `deftype` vs `defprotocol`.)

There seems to be a confusion/confluence between method calls and function calls here in this code and that ends up making it a bit more odd.

The `drake.fs` namespace is being used (as far as I can tell), in `use`, not `require` forms, and in `drake.core`, there is already an `:exclude [file-seq]` because of `file-seq` being in the protocol of `FileSystem` and that naming conflict. Normally, that is circumvented using `require` so you can qualify a symbol in a namespace and keep things more segregated.

Methods on protocols are getting into the other namespaces regardless of if they are being called or not (unless you say `:only [...]`).

---

(Sorry about the length/rantiness)

In my opinion, and from other code I've seen written, one generally wraps java-interop-looking-things (method calls) in clojure function equivalents, normally one line functions with type hinting to prevent reflection.

It doesn't look right to be doing the opposite. 

Using a protocol as one does an interface seems obvious (and is), when you're thinking about objects and methods on them, and mixing them in with `deftype` and `defrecord` brings us back to the comfort of OOP (I know it did for me when I first started writing clojure), but I think the difference when using these tools in clojure is subtle but fairly important.

Types and Records in clojure are not meant to be treated as objects. They *are* objects in the their implementation, but they should be thought of as data, as values, more like datatypes (ala Haskell). And protocols (maybe type-classes in Haskell) are ways that we want to guarantee specific data can be used, slightly more semantically rigorous descriptions on functions.