Re: Pathname needs a makeover

On Wednesday, December 8, 2004, 10:47:49 AM, Daniel wrote:

> Hm...to me a pathname is just a string that happens to
> be in a specific format (i.e. it represents a
> theoretical path on a file system).  I suppose you
> could make Pathname a subclass of Array.  I'd be
> interested to see an implementation of that, if even
> for experimentation.

I'm not suggesting that it _should_ be based on Array, but that
actually makes about as much sense as String.  For example,
Pathname#+.  A pathname is conceptually a list of entries in a
hierarchy.

> As for some methods not making sense for a pathname,
> well, I'm not sure what to say to that other than it
> might make sense for that particular user, knowing
> that it was a subclass of String up front.  But, I see
> your point.

Further, if it subclassed String, you have to explain to your users
that #each and #+ don't work as they (probably) expect.  Unless you
propose to change the meaning of Pathname#+, which would kind of
undermine the whole class :)

>> > - It should not implement methods that raise
>> errors if the pathname does
>> >   not exist.
>> 
>> Not sure what you mean here.

> The various File and Dir class methods, such as
> File.mtime, etc.  Isn't the presumption that our
> pathname may our may not exist?  If so, why include
> methods that may not work?

They work fine, just like

  File.mtime?('/usr/bin/fahslkgjherlkshfekhflas')

works fine.  In fact,

  Pathname.new('/usr/bin/fahslkgjherlkshfekhflas').mtime

will have exactly the same result.
 
>> > - Many methods are implemented manually that could
>> be avoided by
>> > subclassing the String class and mixing in the
>> Enumerable module.
>> 
>> That's not a problem.  Delegation is a useful
>> technique.  Any specific
>> examples that bug you?

> By subclassing String, we could eliminate the need for
> ==, <=>, to_s, inspect, and +.

See above about the + method.

>> * You implementation is missing many methods from the existing
>> Pathname (like the Directory, IO, and Utility methods, as marked in
>> the documentation). Is this intentional?

> Yes (see my point above).

> And now for the warm, fuzzy argument - as it stands
> now the Pathname class feels like a kitchen soup of
> methods - a bunch of stuff slapped together from other
> classes, with a few methods of its own sprinkled in
> for good measure.  It just feels clunky and haphazard.

I'm the opposite.  I really like the kitchen sink of methods in
Pathname.  For example:

  path = Pathname.new('/tmp')
  path += 'example-123'
  unless path.exists?
    path.open('w') do |file|
      file.puts "What a nice OO interface!"
    end
  end

I know my feeling is not universal (PragDave expressed a certain
ambivalence about it in Pickaxe II), but to me, this is the way file
access _should_ be done in an OO language.  I cringe when I see code
like

  File.open(File.join(File.basename(path), rel_path)) {...}

and unfortunately, I see code like that quite often.  Compare:

  path = Pathname.new(path).basename + relpath
  path.open {...}

> But, if folks would prefer delegation to subclassing,
> then I guess much of this is moot. :/

The issue of inheritance vs. delegation is separate from what kind of
methods Pathname should include.  Related though, I guess.

Gavin