This post originated from an RSS feed registered with Ruby Buzz
by Daniel Berger.
Original Post: The Pathname Debate
Feed Title: Testing 1,2,3...
Feed URL: http://djberg96.livejournal.com/data/rss
Feed Description: A blog on Ruby and other stuff.
The Rake bug I recently discovered, and the source of that bug, reminded me of a side project I've been working on. Namely, a complete replacement for the Pathname library.
The current implementation has a few problems (which I've brought up previously on ruby-core). First, and foremost, it doesn't work on Win32 systems. That's bad, especially considering how long it has been included in the standard lib. It should have been refactored by now. The second major problem, in my opinion, is that this library can't decide if a pathname refers to an existant path or only a virtual string. From the docs:
"It does not represent the file itself."
I agree. The problem is that the author then goes on to use the facade pattern for the File and FileTest classes. Think about it. Does it make sense to have a Pathname.exists? or Pathname.size method supported when the file does not exist? It's just a string. A representation of a filename. IT DOES NOT REFER TO AN ACTUAL FILE ON THE FILESYSTEM. We've just established that it does represent an actual file.
So stop mixing in methods that require that the file actually exists to work.
Let me reiterate that a pathname is a string. Don't agree? Say this out loud: "A pathname is-a String". True? You bet it is. Should a facade pattern be used? No. It doesn't make sense. Sorry Matz, but I just think you're dead wrong on this one.
With that in mind, I've started my own rewrite of the Pathname class. The most significant design decision I made was to subclass String (which mixes in Enumerable to boot). This provides some immediate benefits in that I suddenly don't need to manually define methods like freeze, taint, untaint, ==, ===, eql?, hash, inspect, and to_s. After that, it was a matter of dealing with path separator issues and refactoring. I rely far less on regular expressions, preferring a split/join approach wherever possible instead.
One issue I will probably still have to deal with is that most folks seem to like the fact that the current Pathname classes tosses in so many File and Dir related methods because they're very convenient. Do I sacrifice purity for convenience even if it seems utterly illogical? I'll think about it.
In any case, I'm eventually going to release this to the public a *replacement* for the current Pathname class, and I'm not going to be very apologetic about it either. If you don't like it, tough.
Previous Topic
