Re: Pathname needs a makeover

On Wednesday, December 8, 2004, 7:51:11 AM, Daniel wrote:

> Hi all,

> I've taken a look at the Pathname class.  In my humble opinion, it needs
> a makeover.

> Here are a list of how I think it ought to behave:

> - A pathname is a string.  Therefore, it should be a subclass of String

I don't see a good reason for that.  You mention a practical reason
below and a theoretical reason above.  Practical reasons don't sway
me, because there are more practical solutions (like delegation).  And
I disagree with the theoretical reason.  A pathname is a pathname, not
a string.  It could just as well be implemented as an array.  Things like

  pathname[1..15]           and
  pathname.center(30)

do not make sense when you consider what 'pathname' is supposed to be.
I know we generally take a permissive approach with Ruby code, but I
think we should look for the best design possible with stdlib classes,
and a good design should clearly communicate the intention of the
class.

I _would_ like to see Pathname#to_str be equivalent to #to_s, so I'm
kind of contradicting myself.

> - It should be possible to break a pathname down into component parts
>   and iterate over them.  Therefore, it should mixin Enumerable.

That "therefore" doesn't hold.  Iterating over them requires an 'each'
method.  That doesn't mean that mixing in Enumerable is a bad idea,
but I'd like to see better justification.

> - It should not implement methods that raise errors if the pathname does
>   not exist.

Not sure what you mean here.

> - It should work for both Unix and Win32 style pathnames.

Agreed.

> - It should make private methods private.

Agreed.

> Here are the specific problems I have with the current class:

> - 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?

> - The to_a method does not return something useful.

Good point.

> - Some methods that I suspect should be private (e.g.
> cleanpath_aggressive) should be made private.

Agreed.

> - Some of the methods require that the pathname actually exist.  IMHO,
>   since a pathname is just a string, and we don't know (or care) if it exists,
>   we should not implement methods that raise an error if it doesn't exist.

Again, not sure what you mean.  I find Pathname quite agreeable in
this sense: most methods manipulate pathnames without caring whether
the resulting path exists.  Where methods _do_ access the filesystem,
it is documented.

Can you give examples of your grievance?

> Below is an incomplete version of what I had in mind (it still needs
> realpath, cleanpath, etc), but you should get the drift.  What do folks
> think?

* (BTW String already includes Enumerable.)

* The following line looks flaky to me.  The condition should at least
  be spelled out clearer.

    @sep = (File::ALT_SEPARATOR) && (@path =~ /\\/) ?
      File::ALT_SEPARATOR : File::SEPARATOR

* #root could avoid calling #split twice

* 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?

> [code snipped]

Gavin