davidsantiago / pathetic Goto Github PK

I believe these two URLs are different and should not return the same result. On most servers they point both to the same thing, but that is not the default behavior.

(url-normalize "http://example.org/dir/image")
=> "http://www.example.org/dir/image"
(url-normalize "http://example.org/dir/image/")
=> "http://www.example.org/dir/image"

The cljsbuild plugin pulls in clojurescript as a runtime dependency. Both cljx and cljsbuild are used to build the project, and should be placed in the dev profile.

IMHO there is a conceptual problem with the library. But first, the concrete issues:

The library won't even load on Windows because

(re-pattern File/separator)

is illegal in Windows where path separator is "". "" must be escaped inside a regex. But, that could be easily solved doing

(re-pattern (Pattern/quote File/separator))

Once that is done, you'd need to correct a couple of places where separator and separator-pattern are confused in the code, since you can't treat them as equal once the pattern is escaped.

Now to the (IMHO) conceptual problem: The library intends to provide Unix like path operations, File/separator shouldn't appear anywhere in the code. Users from any OS should always use "/" with this library, the fact that there is a different separator in their systems has nothing to do with it, the library only takes care of unix-like paths only.

For the same reason, arguments can't never be instances of java.io.File, since those are system dependent (in windows (File. "/") gets converted to (File. "\\")). Those tests using File as argument are condemned to fail in Windows.

In conclusion, why so many (File.) and File/separator everywhere? According to what I understand there shouldn't be any, and that way the library would work as intended in any platform.

Go with

(def ^{:private true} default-separator "/")

and remove any tests and documentation mentioning File instances as arguments.

Sorry about the length and abstract nature, hope it helps

Right now, these fns all take and return strings. It'd be great if alternatives (e.g. normalize*, relativize*, resolve*) accepted and returned vector representations of the paths involved. Obviously, the current API would delegate to those alternatives (almost as simple as e.g. (comp render-path normalize* parse-path)).